Banco de dados lento? Como achar gargalos de IOPS no Linux

Por que o banco de dados trava quando há muitas escritas simultâneas?

Quando uma aplicação cresce, é comum culpar a falta de memória RAM ou consultas SQL mal escritas pela lentidão geral do sistema. No entanto, em cenários de alta concorrência de escritas, o verdadeiro vilão costuma ser o subsistema de armazenamento. As requisições se acumulam porque o hardware de disco não consegue processar os pedidos na velocidade exigida pelo banco de dados.

Na prática, isso significa que o banco de dados precisa registrar cada transação confirmada em arquivos de log em disco para garantir durabilidade, conforme as propriedades ACID. Quando centenas de clientes tentam alterar dados ao mesmo tempo, a fila de espera do disco cresce exponencialmente. Entender esse comportamento exige olhar além das métricas habituais de CPU e mergulhar no comportamento do Kernel do Linux.

Para aprofundar a investigação sobre o desempenho das suas consultas antes de culpar exclusivamente o hardware, vale a pena conferir nosso guia prático sobre otimização de índices no PostgreSQL. Afinal, índices ineficientes forçam varreduras completas em tabelas, gerando ainda mais tráfego desnecessário de leitura e escrita nos discos.

O que são IOPS e por que eles decidem a vida útil da sua aplicação

IOPS significa Input/Output Operations Per Second, ou operações de entrada e saída por segundo. Em termos simples, é a quantidade de vezes que o seu disco consegue ler ou escrever blocos de dados em um intervalo de um segundo. Diferente da taxa de transferência em megabytes por segundo, os IOPS medem a capacidade de lidar com muitas requisições pequenas e simultâneas.

Bancos de dados relacionais geram milhares de pequenas operações de escrita o tempo todo, atualizando índices, tabelas e logs de transação. Se um disco mecânico tradicional oferece cerca de cem IOPS, ele vai travar imediatamente se receber mil requisições de gravação por segundo. Os SSDs modernos e volumes NVMe em nuvem ampliam drasticamente esse limite, mas ainda assim possuem um teto operacional rígido.

Como usar o iostat para revelar a saturação real do disco

A ferramenta de linha de comando iostat faz parte do pacote sysstat e serve para monitorar o uso da CPU e o desempenho de partições de disco. Ela mostra o quanto os discos estão ocupados e quanto tempo as requisições demoram para ser respondidas. Para iniciar um diagnóstico preciso em tempo real, execute o comando a seguir no terminal do seu servidor Linux:

iostat -xz 2 10

Esse comando exibe relatórios detalhados a cada dois segundos, repetindo a leitura dez vezes. O argumento -x adiciona métricas estendidas fundamentais, enquanto o -z oculta dispositivos que estão ociosos, mantendo a tela limpa apenas com os discos ativos e relevantes para a análise.

Interpretando as métricas críticas: await, %util e svctm

Dentro da saída gerada pelo iostat, algumas colunas merecem atenção redobrada do engenheiro. A coluna %util indica a porcentagem de tempo em que o disco esteve ocupado processando requisições. Se esse valor estiver consistentemente próximo de cem por cento, significa que o dispositivo chegou ao seu limite físico de capacidade.

Outro indicador vital é a coluna await, que mede o tempo médio em milissegundos que cada operação de E/S levou para ser concluída, incluindo o tempo na fila e o tempo de processamento real. Se o await dispara para dezenas ou centenas de milissegundos, as conexões do banco de dados começam a estourar o tempo limite, causando as famosas falhas de timeout na aplicação.

Como descobrir qual processo está sufocando o armazenamento

Saber que o disco está sobrecarregado é apenas o primeiro passo; o próximo desafio é descobrir qual processo está causando o problema. Em servidores que executam múltiplos serviços, como o banco de dados, servidores web e ferramentas de monitoramento, a culpa nem sempre é óbvia.

Para isolar o consumo de E/S por processo, a ferramenta pidstat oferece uma visão cirúrgica da atividade de disco. Executar o comando abaixo permite rastrear os processos que mais gravam dados no armazenamento:

pidstat -d 2 5

Com essa saída, você consegue identificar exatamente se é o processo do PostgreSQL, do MySQL ou algum script de backup em segundo plano que está monopolizando a largura de banda do disco e estrangulando o banco de dados principal.

Estratégias práticas para mitigar gargalos de escrita e salvar seu sistema

Quando o diagnóstico aponta um gargalo genuíno de IOPS, existem caminhos técnicos imediatos para aliviar a pressão no armazenamento. O primeiro passo envolve revisar as configurações de checkpoint do banco de dados, permitindo que o sistema acumule mais alterações na memória RAM antes de despejá-las no disco de uma só vez.

Outra alternativa é habilitar gravações assíncronas em tabelas de log secundárias onde a perda de alguns milissegundos de dados não represente um risco financeiro ou legal. Além disso, migrar para volumes de armazenamento baseados em NVMe com capacidade de IOPS provisionados garante que picos sazonais de acesso não derrubem a aplicação em produção. Para complementar essa implementação em produção, vale conferir também nossas análises técnicas sobre Como blindar aplicações de IA contra prompt injection e Como usar WebAssembly no frontend para tarefas pesadas.

Conclusão e próximos passos para manter seu banco saudável

O diagnóstico de latência de disco em bancos de dados exige olhar além das telas bonitas de monitoramento em nuvem e entender o comportamento real do sistema operacional. O uso correto de comandos como iostat e pidstat transforma palpites subjetivos em dados concretos, permitindo que você atue diretamente na raiz do problema de performance.

Manter uma cultura de monitoramento contínuo do subsistema de armazenamento evita surpresas desagradáveis durante picos de tráfego. Ao combinar ajustes finos de configuração no banco de dados com uma infraestrutura de hardware adequada, sua aplicação ganha a resiliência necessária para crescer sem sacrificar a estabilidade operacional.