Saltar para o conteúdo 
Mostro passo a passo como a análise de espera de E/S com o iostat e o vmstat torna visíveis os estrangulamentos e quais as métricas do servidor Linux que contam para tempos de resposta rápidos. Ao fazê-lo, defino limites claros, interpreto padrões típicos e sugiro medidas concretas para otimizar E/S e CPU em.
Pontos centrais
- iostat e vmstat fornecem uma visão complementar da carga da CPU e do armazenamento.
- wa via 15-20% e %utile via 80% mostram um estrangulamento de E/S.
- aguardar e avgqu-sz explicar a latência e as filas de espera.
- mpstat detecta a carga distribuída de forma desigual pelos núcleos da CPU.
- Afinação varia de MySQL para os parâmetros e armazenamento do kernel.
O que significa I/O Wait em servidores Linux?
Em espera de E/S, a CPU aguarda inutilmente porque está à espera de memória ou dispositivos de rede mais lentos, o que é conhecido como wa-valor em ferramentas como top ou vmstat. Avalio esta proporção como o tempo em que as threads bloqueiam e os pedidos são concluídos mais tarde, o que os utilizadores sentem diretamente como lentidão. Valores acima de 10-20% geralmente indicam uma Armazenamento-Por exemplo, quando os discos rígidos, as matrizes RAID ou as montagens NFS são utilizadas até à sua capacidade máxima. Em configurações de alojamento com bases de dados, as consultas não indexadas e os picos de escrita resultam em tempos de espera desnecessários no Disco. Se quiser rever os conceitos, pode encontrar os conceitos básicos em Entender a espera de E/S, antes de ir para o consultório.
Início rápido: ler o vmstat corretamente
Com o vmstat posso verificar o mais importante Linux-e reconhecer padrões iniciais sem muito esforço. A chamada vmstat 1 10 fornece dez instantâneos nos quais presto atenção especial às colunas wa (I/O wait), bi/bo (block I/O) e si/so (swap). Para mim, valores altos de bo com aumento simultâneo de wa indicam muitos acessos de escrita bloqueados, o que geralmente indica limites de buffer ou mídia lenta. Se si/so permanecer em zero, mas wa aumentar significativamente, a suspeita de pura Armazenamento-limite. Em hosts com vários núcleos, eu combino o vmstat com o mpstat -P ALL 1, porque a espera de E/S geralmente afeta apenas núcleos individuais e, portanto, parece mais inofensiva em média do que realmente é.
Imagem fina da CPU: us/sy/st, fila de execução e comutação de contexto
Com o vmstat e o mpstat eu leio mais do que apenas wa: Alta nósO trabalho de aplicação "pesado em termos de computação" é apresentado nas secções seguintes, sy indica o trabalho do kernel/driver, por exemplo, com E/S. Em ambientes virtualizados, presto atenção a st (Roubo): Valores altos de st significam que a VM perde tempo de CPU, o que aumenta artificialmente as latências com um padrão de E/S idêntico. Também comparo a fila de execução (r no vmstat) com o número de CPUs: Um r permanentemente mais alto do que o número de CPUs indica congestionamento na CPU, não no Armazenamento. Muitas alterações de contexto (cs) em combinação com pequenas escritas síncronas são um indicador de padrões de E/S tagarelas. Dessa forma, evito interpretar erroneamente a falta de CPU como um problema de E/S.
Compreender o iostat em profundidade: métricas importantes
iostat -x 1 dá-me o extended Disco-métricas que descrevem claramente a latência, a utilização e as filas de espera. Inicio a medição para picos de carga e correlaciono %util, aguardo, svctm e avgqu-sz para distinguir causa e efeito. Se o %util subir para 90-100%, enquanto o await e o avgqu-sz também sobem, vejo uma saturação de Prato ou um volume limitado. Se aguardar mostra valores elevados com %util moderado, verifico se há interferência de cache, limites do controlador ou pedidos individuais de grande dimensão. r/s e w/s trazem a frequência para a imagem, enquanto MB_read e MB_wrtn explicam o volume, o que me fornece valores comparativos importantes para SSD dedicados e configurações NVMe.
NVMe, SATA e RAID: o que significam %util, aguardar e profundidade de fila
Faço uma distinção rigorosa entre os tipos de media: DISCO RÍGIDO mostrar maior aguardar-valores mesmo com uma pista moderada, porque os movimentos da cabeça dominam. SSD/NVMe escalam bem com o paralelismo, razão pela qual um valor mais elevado de avgqu-sz pode ser normal, desde que aguardar permanece dentro dos limites. No NVMe com várias filas de submissão/conclusão, leio o %util com mais cautela: os dispositivos individuais podem já estar no limite a 60-70% se a aplicação não gerar paralelismo suficiente ou a profundidade da fila (nr_requests, profundidade_da_fila) é demasiado pequeno. No RAID Verifico se a E/S aleatória dispersa encontra tamanhos de faixas demasiado pequenos; depois aguardar e %utile de forma desigual nos discos membros. Por isso, olho para o iostat por dispositivo membro, não apenas no volume composto, para tornar visíveis os hotspots. Para camadas estruturadas em log (por exemplo, copy-on-write), espero latências ligeiramente mais elevadas para as escritas, mas compenso isso com janelas de writeback alargadas ou batching do lado da aplicação.
Fluxo de trabalho de diagnóstico para tempos de espera longos
Eu inicio cada análise em paralelo com vmstat 1 e iostat -x 1 para que eu possa ver os estados da CPU e o status do dispositivo de forma síncrona e atribuí-los ao tempo. Em seguida, uso mpstat -P ALL 1 para verificar se os núcleos individuais estão funcionando de forma incomum. wa o que evita valores médios interpretados incorretamente. Se houver indicações de uma causa, utilizo o pidstat -d ou o iotop para ver exatamente qual o PID que está a utilizar a maior parte das partilhas de E/S. Em ambientes de alojamento com bases de dados, começo por distinguir entre picos de leitura e de escrita, uma vez que as estratégias de write-back e os padrões de fsync geram sintomas muito diferentes e podem, por isso, ser usados para Medidas tornam-no possível. Para questões de armazenamento mais aprofundadas, uma visão geral como a que se encontra em Gargalo de E/S no alojamento, antes de mexer no kernel ou no sistema de ficheiros.
Demarcação clara entre virtualização e contentores
Nas VMs, considero wa juntamente com st (Roubo) e, adicionalmente, medir no hipervisor, porque só aí os dispositivos reais e Tacos são visíveis. As agregações de armazenamento (thin provisioning, dedupe, snapshots) movem os picos de latência para baixo na pilha - na VM, isso tem o seguinte efeito aguardar salta, enquanto o %util permanece discreto. Nos contentores, limito ou desacoplo E/S com as regras do Cgroup (por exemplo, limites de IOPS/throughput), a fim de Vizinhos barulhentos para os domar. Eu documento os limites por serviço para que os valores medidos sejam reproduzíveis e os alarmes mantenham o seu contexto. Importante: Um alto wa na VM podem ser acionados por backups, scrubs ou reconstruções em todo o anfitrião - correlaciono os tempos com os trabalhos do anfitrião antes de tocar na aplicação.
Limites, limiares e próximas etapas
Utilizo alguns limites claros para decidir se existe um verdadeiro estrangulamento e quais as medidas a tomar para estabilizar visivelmente o desempenho. Tenho em conta o tipo de suporte, a carga de trabalho e os requisitos de latência, porque os mesmos valores em HDD e NVMe têm implicações diferentes. Utilizo a tabela seguinte como um guia rápido que utilizo nos meus manuais. Meço várias vezes ao longo de minutos e sob carga, para que os valores atípicos não gerem falsos alarmes e eu possa reconhecer tendências. Utilizo isto como base para acções específicas, em vez de substituir reflexivamente o hardware ou o Parâmetros em grande escala.
| Métricas | Limiar | Interpretação | Próximas etapas |
|---|---|---|---|
| wa (vmstat) | > 15-20% | Tempo de espera de E/S significativo | Verificar o iostat; encontrar a causa com o pidstat/iotop; analisar o caching e as escritas |
| %utile (iostat) | > 80-90% | Dispositivo utilizado | correlacionar await/avgqu-sz; verificar a profundidade da fila, o agendador, o RAID e o SSD/NVMe |
| aguardar (ms) | > 10-20 ms SSD, > 30-50 ms HDD | Aumento da latência | Diferenciar entre aleatório e sequencial; personalizar as opções do sistema de ficheiros, writeback, journaling |
| avgqu-sz | > 1-2 persistente | A fila de espera aumenta | Acelerar/aumentar o paralelismo; otimizar o padrão de E/S da aplicação; verificar os limites do controlador |
| si/so (vmstat) | > 0 em carga | Gargalo de armazenamento | Aumentar a RAM; afinação da consulta/cache; verificar a capacidade de troca/limites de memória |
Causas na pilha: BD, sistema de ficheiros, virtualização
Com as bases de dados, vejo frequentemente junções não indexadas, buffers demasiado pequenos e chamadas fsync excessivas, uma vez que o Causas para valores de espera elevados. Verifico os planos de consulta, ativo os registos para instruções lentas e ajusto os tamanhos, como o buffer pool do InnoDB, os tamanhos dos ficheiros de registo e os ficheiros abertos de forma objetiva. Ao nível do sistema de ficheiros, analiso as opções de montagem, os modos de journal e o alinhamento com a faixa RAID, porque as combinações erradas fazem explodir os tempos de espera. Em configurações virtualizadas, não confio apenas em medições na VM, mas olho para o host, pois é aqui que os dispositivos de bloco reais e os Tacos tornam-se visíveis. Isto permite-me separar claramente os efeitos da desduplicação, do aprovisionamento reduzido ou das VMs vizinhas dos padrões da aplicação.
Sistema de ficheiros e opções de montagem em pormenor
Avalio os sistemas de ficheiros em função do volume de trabalho: ext4 em modo ordenado ou de writeback minimiza as barreiras à intensidade de escrita, enquanto que XFS com a sua conceção de registo para cargas de trabalho paralelas. Opções como não há tempo ou relatime reduzir as escritas de metadados, hora da preguiça move as actualizações de carimbo de data/hora para o writeback em pacotes. Para o journaling, verifico os intervalos de commit (por exemplo, commit=) e verifico se os force flushes (barreiras) são exacerbados pelas políticas de cache do controlador. No RAID, presto atenção ao alinhamento limpo com a faixa (Parted/FDISK com início de 1MiB), caso contrário aguardar através do método Ler-Modificar-Escrever, mesmo com padrões supostamente sequenciais. No caso das bases de dados, utilizo frequentemente estratégias O_DIRECT ou de descarga direta do registo - mas apenas após medição, porque a cache do sistema de ficheiros pode reduzir drasticamente a carga de leitura se o conjunto de trabalho couber nela.
Afinação: do kernel à aplicação
Começo com ganhos simples, por exemplo, indexação de consultas, gravação em lote e configuração sensata de pooling de conexões, antes de começar no nível do sistema. Para o writeback, ajusto vm.dirty_background_ratio, vm.dirty_ratio e vm.dirty_expire_centisecs de forma controlada para que o sistema escreva de forma contígua e gere menos bloqueios sem obstruir a memória. Para os dispositivos de bloco, verifico o agendador de E/S, a profundidade da fila e o avanço de leitura, porque estes parâmetros moldam diretamente a latência e o débito. Nos controladores RAID, afino o tamanho das faixas e a política de cache, enquanto nos SSD/NVMe para firmware, TRIM e configurações consistentes de superprovisionamento. Após cada alteração, verifico com o vmstat e o iostat durante vários minutos se a espera diminui e se o %util permanece estável antes de dar o próximo passo.
Interrupções, NUMA e afinidades
Monitorizo a carga de IRQ e a topologia NUMA porque ambas têm um efeito notável nas latências. NVMe-Eu vinculei as interrupções às CPUs do domínio NUMA do controlador por afinidade, para que os caminhos de dados permanecessem curtos. Se a tempestade de IRQs estiver a ser executada num núcleo, vejo sy e o resto das CPUs parecem estar inactivas; mpstat expõe isso. Só permito o irqbalance se a distribuição corresponder ao hardware - caso contrário, defino afinidades específicas. Eu também verifico se a aplicação e seu E/S trabalham na mesma zona NUMA (localização de armazenamento), porque os acessos entre sockets causam tempos de espera em aguardar pode ser mascarado.
Automatizar e visualizar a medição
Para ter a certeza de que reconheço as tendências, automatizo as medições e integro o iostat/vmstat nas ferramentas de monitorização, que podem ser utilizadas para analisar dados históricos. Dados salvar. Defino alarmes de forma conservadora, por exemplo, de wa > 15% em vários intervalos, combinados com limites para aguardar e %util para evitar falsos alarmes. Para telas de métricas gerais, uso painéis que justapõem métricas de CPU, armazenamento, rede e aplicativo para que as correlações sejam imediatamente visíveis. Se precisar de uma introdução às métricas, pode encontrá-las em Métricas do servidor contexto compacto para o trabalho quotidiano. Para mim, é importante ter um processo repetível: medir, formular uma hipótese, fazer ajustes, medir novamente e analisar os resultados. Resultados documento.
Ensaios de carga reprodutíveis com fio
Se não tiver uma carga real ou quiser verificar hipóteses, utilizo fio-Testes. Simulo padrões representativos (por exemplo, leitura aleatória de 4k, escrita sequencial de 64k, perfis mistos 70/30) e vario iodepth, para definir a janela do ponto ideal entre aguardar e rendimento. Separo rigorosamente os caminhos de teste dos dados de produção e anoto as condições de limite (sistema de ficheiros, opções de montagem, agendador, profundidade da fila) para poder categorizar os resultados corretamente. Após a afinação, os mesmos testes são utilizados como uma verificação de regressão; apenas quando aguardar e %utile para que o aspeto seja consistentemente melhor, aplico alterações à superfície.
Reconhecer padrões de erro: padrões típicos
Se observar um wa elevado com um %utile simultaneamente elevado e um avgqu-sz crescente, tudo aponta para uma saturação do Dispositivo, ou seja, limites físicos reais. Valores elevados de await com %util moderado tendem a indicar peculiaridades do controlador ou da cache, como barreiras, write-through ou flushes esporádicos. Valores crescentes de si/so juntamente com quedas no cache indicam claramente uma falta de RAM, que aumenta artificialmente a E/S e aumenta os tempos de espera. Se o disco permanecer discreto, mas a aplicação enquadrar gravações grandes e com muita sincronização, transfiro o trabalho para a escrita assíncrona, pipelining ou Lote-mecanismos. Em configurações de NFS ou de armazenamento em rede, também verifico a latência, o MTU, as retransmissões e o caching do lado do servidor, porque o tempo de rede é diretamente mascarado como latência de E/S aqui.
NFS/iSCSI e armazenamento distribuído
Em NFS e iSCSI, faço a distinção entre dispositivo e caminho de rede: iostat apenas mostra o que a camada de blocos vê - também reconheço retransmissões, latências e problemas de janela através de métricas de rede. Alta aguardar com moderada %utile no dispositivo de bloco virtual é típico quando a rede pára ou o cache do lado do servidor esfria. Para o NFS, verifico as opções de montagem (rsize/wsize, proto, sync/async) e o lado do servidor (threads, políticas de exportação, cache); para o iSCSI, os parâmetros de sessão e fila. Planeio janelas de manutenção para trabalhos de servidor (scrubs, rebuilds, rebalanceamento) de modo a não saturar o armazenamento partilhado em alturas de pico e, assim, fazer com que o servidor fique indisponível. wa em todos os clientes.
Exemplos práticos: três cenários curtos
Grupo de blogues com dicas de escrita
No horário nobre, os comentários e a invalidação da cache aumentam, o que faz com que o await e o avgqu-sz no iostat aumentem significativamente, enquanto o %util se mantém em 95%. Aumento suavemente os parâmetros de writeback, optimizo a invalidação da cache ao nível do caminho e aumento o buffer de registo do InnoDB para que haja menos pequenas escritas sincronizadas. Depois disso, o await diminui de forma mensurável, os valores de bo permanecem elevados, mas o wa diminui, o que reduz imediatamente os tempos de resposta. Ao mesmo tempo, substituo HDDs individuais por SSDs para o diário, o que alivia adicionalmente o gargalo. O padrão mostra como Lote-Combinar a escrita e o registo diário mais rápido.
Comprar com picos de leitura e índices de pesquisa
As promoções geram uma carga de leitura pesada, o r/s dispara, a espera mantém-se moderada, mas a aplicação continua a reagir com lentidão à navegação por filtros. Reconheço muitas consultas sem buffer sem índices adequados que excedem o conjunto de trabalho da cache do sistema de ficheiros. Com a indexação direcionada e a reescrita de consultas, a r/s desce, os hits estão mais frequentemente na cache e o iostat confirma um MB_read mais baixo com a mesma taxa de transferência. Ao mesmo tempo, eu aumento ligeiramente o read-ahead para servir varreduras seqüenciais de forma mais eficiente, o que reduz ainda mais as latências. É assim que eu verifico que Ler-Os padrões conduzem novamente a acessos à cache.
Anfitrião de VM com „vizinho ruidoso“
Em VMs individuais, o top mostra um wa elevado, mas o iostat na VM só vê dispositivos virtuais com uma utilização enganadora. Também faço medições no hipervisor, vejo dispositivos de bloco reais saturados e identifico uma VM vizinha com backups agressivos como a causa. Limites de largura de banda e janelas de backup modificadas estabilizam o await e o %util em todo o host. Em seguida, meço novamente na VM e no host para confirmar e evitar o efeito em ambos os lados. Isso confirma que a real Dispositivos-A métrica mostra sempre a verdade no anfitrião.
Lista de controlo para o próximo incidente
Eu inicio os logs e medições primeiro para que nenhum sinal seja perdido, e mantenho o vmstat 1 e o iostat -x 1 rodando por vários minutos. Em seguida, correlaciono os picos com os eventos da aplicação e os temporizadores do sistema antes de identificar os processos individuais com o pidstat -d e formular hipóteses. O próximo passo verifica a memória, swap e cache hits para que a falta de RAM não seja incorretamente reconhecida como Disco-aparece o problema. Só depois de ter isolado a causa é que altero exatamente uma coisa, registo a configuração e avalio o efeito no await, %util e wa. Dessa forma, mantenho a análise reproduzível, aprendo com cada incidente e reduzo o tempo para o Solução claramente.
Erros de interpretação e obstáculos frequentes
Não me deixo enganar por picos isolados: Segundos isolados com alta wa são normais, apenas os planaltos persistentes indicam um estrangulamento estrutural. %utile próximo de 100% só é crítico se aguardar sobe ao mesmo tempo - caso contrário, o dispositivo está simplesmente ocupado. Ligado SSD/NVMe é uma maior avgqu-sz muitas vezes intencional, a fim de utilizar o paralelismo interno; só o reduzo quando os objectivos de latência não são atingidos. Verifico o escalonamento da frequência da CPU: a poupança agressiva de energia pode aumentar os tempos de resposta e, por conseguinte wa parecem piorar. E eu separo o TTFB da aplicação da latência do armazenamento - a rede, os handshakes TLS e os serviços a montante podem produzir sintomas semelhantes sem iostat „é “culpado".
Breve resumo para os administradores
A análise de espera de E/S com iostat e vmstat funciona rapidamente se eu ler wa, await, %util e avgqu-sz juntos e relacioná-los com o contexto da carga de trabalho. Em primeiro lugar, identifico se existe uma saturação real do dispositivo ou se os padrões de memória e de aplicações estão a provocar a latência e, em seguida, selecciono a alavanca adequada. Pequenos ajustes direcionados a consultas, parâmetros de writeback, agendadores ou profundidade de fila têm frequentemente o maior efeito antes de serem necessárias alterações dispendiosas ao hardware. Medição, hipótese, alteração e nova medição continuam a ser a minha sequência fixa para que as decisões sejam compreensíveis e repetíveis. É assim que mantenho Linux-O servidor é reativo e garante uma melhoria notável Tempos de resposta sob carga.
