Eu entendo que o IO espera quando eu o vejo em um servidor, isso significa que a CPU está bloqueada enquanto eu aguardo o IO para recuperar [fonte] .
Estou tentando entender por que as estatísticas de SAN mostrariam uma alta espera por IO - isso indica que a CPU da SAN está bloqueada pelo disco da SAN ou é outra coisa?
Uma SAN tem uma latência de IO muito maior do que um disco local devido às leis fundamentais da física. Portanto, se seu aplicativo estiver fazendo muitas gravações pequenas e fsync() após cada, você verá muito iowait.
Por exemplo, aqui estão dois replicadores mysql do mesmo conjunto de dados contendo muitas pequenas transações, você verá que o escravo na SAN está gastando muito mais tempo fazendo IO.
San:
Local:
O tempo de espera da SAN pode significar que seu armazenamento é o gargalo. Também pode ser configurações do servidor ou a conexão entre seus servidores e o armazenamento, mas com muito mais frequência, quando vejo o tempo de espera de um disco de SAN, é simplesmente uma SAN ocupada.
Primeiro, verifique o desempenho nos discos que fazem o backup do volume. Você está procurando picos em leituras ou gravações de IO / s ou MB / s e, potencialmente, um pico na utilização do cache. Tente olhar apenas para o hardware envolvido no volume que você está investigando. Além disso, olhe para trás e para a frente no tempo um pouco para ver se houve picos mais altos que não causaram problemas. Em caso afirmativo, é improvável que o hardware de armazenamento tenha sido o problema. A ação corretiva para o gargalo de hardware no armazenamento pode incluir a migração desse volume para outro pool ou RAID ou o aumento do número de spindles ou cache.
Em segundo lugar, verifique as configurações de profundidade da fila no servidor. Se você tiver uma profundidade de fila muito alta, seu servidor verá latências mais altas durante períodos de utilização pesada. A profundidade da fila é uma maneira de o armazenamento informar ao servidor para acelerar o IO, permitindo que o armazenamento seja recuperado. 32 é um bom número médio que seria suportado pela maioria dos sistemas operacionais de servidor e pela maioria dos dispositivos de armazenamento que já vi. Eu também vi trabalhos cada vez mais altos, mas se for definido como 1024 ou algo assim, isso poderia explicar altos tempos de espera. Em uma situação em que a profundidade da fila é muito alta, o servidor enfileira tudo o que deseja fazer e, em seguida, o armazenamento faz isso tão rápido quanto teria se a profundidade da fila fosse muito menor. Como o servidor mede o tempo de espera de quando algo entra na fila e sai da fila, o tempo de espera aumentaria.
Por fim, verifique os logs de erros do servidor. Certifique-se de que não haja problemas no nível da transferência (como tempos limite de disco ou falhas de caminho). Se houver, você gostaria de investigar o interruptor.
Não é medido de forma diferente do que em um servidor: há mais pedidos de I / O que podem ser resolvidos pelos recursos de hardware disponíveis.
A alta solicitação de E / S conforme relatado pelo software de gerenciamento da SAN significa que o hardware da SAN não consegue acompanhar as demandas de seus clientes da SAN. Isso ocorre porque seu hardware simplesmente não tem capacidade para sua carga, ou pode ser algo que está falhando e com baixo desempenho.
Uma unidade com falha lenta que causa um desempenho ruim é realmente muito comum, especialmente em configurações RAID5. Puxe os registros SMART de todas as suas unidades e aposto que você encontra uma unidade com um número muito alto de erros corrigidos. (Corrigir esses erros leva tempo. Se um erro individual for corrigido dentro de um certo período de tempo, o controlador RAID não registra um erro. Mas acumule muitos desses erros e isso significa muito tempo. como você obtém um desempenho ruim.)