Por que um aplicativo com uso intenso de disco seria executado mais rapidamente em uma SAN do que em um disco físico? Eu teria esperado que o disco físico fosse um pouco mais rápido, mas na verdade o processo funcionou 100 vezes mais rápido quando a unidade de trabalho estava definida para uma partição na SAN.
Nosso palpite é que a SAN é otimizada para ser rápida, enquanto as configurações de ajuste de disco físico são relacionadas ao SO (Solaris) e não foram tocadas ou o SO foi corrigido.
Durante a atividade mais alta, a E / S de disco estava sendo executada a 100% e o tempo para concluir uma gravação era superior a 2 segundos, pois vários processos estavam gravando no disco ao mesmo tempo.
(O aplicativo envolvido era o Informatica PowerCenter)
Eu não estou nada surpreso. Os arrays SAN geralmente têm muitos discos envolvidos. O fator limitante para E / S de disco é a velocidade do disco individual e essa pilha. 6 unidades locais em um RAID10 terão desempenho melhor que 2 e 80 unidades em uma SAN terão desempenho melhor que 10 unidades localmente. Existem variáveis, é claro, mas é assim que funciona.
Além disso, se a SAN tiver algum SSD envolvido, as coisas ficarão realmente agitadas.
É quase certamente devido ao cache. O DAS provável tem um cache mínimo, em que a maioria das SANs corporativas possui vários gigabytes de cache. Eu acho que o aplicativo está saturando o cache do DAS, mas não o do SAN.
Conceitualmente, parece que a veiculação de disco da SAN deve ser mais lenta do que servi-lo localmente. No entanto, existem muitos fatores que podem reverter isso e fazer com que a SAN seja uma opção muito mais rápida. Alguns desses fatores são:
Tudo isso afetará seu desempenho na SAN e no disco local.
Tudo se resume a quantos fusos estão disponíveis ... Quanto maior o número de fusos, mais rápido será acessar qualquer dado dado. se você é um IO intensivo, especialmente se você for um aplicativo de banco de dados, poderá facilmente enterrar o desempenho do disco local com uma solução SAN que pode ter um número muito maior de conjuntos de discos para o gerenciamento de dados, índices e outros.
Com o subsistema de disco local, você provavelmente também compartilha o acesso aos cabeçotes de leitura / gravação com outras operações, como r / w para troca, acesso local a arquivos e bibliotecas, acesso a aplicativos, etc. o tempo coletivo para todas as ações de leitura / gravação para mover as cabeças de leitura / gravação de uma área do disco para cobrir um conjunto de ações para outra, a fim de satisfazer os requisitos da sua aplicação, pode certamente superar o desempenho.