Gargalo de I/O em Discos NVMe e Lentidão de Escrita em Bancos MySQL de Alta Concorrência

Muita gente acha que colocar um disco NVMe resolve qualquer lentidão de banco de dados. Só que no MySQL e MariaDB usando o motor InnoDB, o gargalo de escrita muitas vezes não tem a ver com a velocidade bruta do disco, mas com a quantidade de vezes que o banco força o sistema operacional a confirmar a gravação física no chip de memória flash. Quando dezenas de transações acontecem por segundo, essas chamadas formam uma fila de espera que faz o tempo de resposta do servidor subir e trava a navegação dos usuários. Entenda como medir isso e como configurar seu banco para trabalhar direito em Otimização de Sites e Servidores.

Tópicos abordados

• 1. Por que o MySQL faz tantas chamadas de fsync()
• 2. Como usar o iostat para achar a fila de escrita
• 3. Os parâmetros principais para mudar no my.cnf
• 4. Os riscos reais de mudar a durabilidade das transações
• 5. O que essa lentidão de banco faz com o seu SEO
• 6. Como resolver a velocidade do seu banco de dados

1. Por que o MySQL faz tantas chamadas de fsync()

Para garantir que nenhum dado de venda ou cadastro seja perdido se a energia do servidor cair, o motor InnoDB usa uma propriedade chamada durabilidade. Cada vez que uma transação termina com COMMIT, o MySQL pede ao sistema operacional para descarregar os dados do buffer da memória direto para os blocos físicos do NVMe usando uma chamada chamada fsync().

Mesmo em um NVMe veloz, cada sincronização física leva alguns microssegundos. Se você tem 500 pessoas navegando, colocando produtos no carrinho, atualizando sessões e disparando webhooks, o banco tenta fazer milhares de chamadas de sincronização ao mesmo tempo. As threads do MySQL começam a disputar a vez de gravar, a fila enche e o servidor começa a demorar segundos para responder qualquer consulta simples.

2. Como usar o iostat para achar a fila de escrita

Para confirmar se o disco está travando as operações, instale o pacote sysstat e rode este comando no terminal enquanto o site estiver recebendo visitas:

iostat -xz 1 10

Foque em duas colunas específicas do relatório:

• w_await: Mostra o tempo médio em milissegundos que cada escrita espera para ser atendida. Em um disco NVMe bom, esse número deve ficar abaixo de 1.0ms. Se estiver batendo 5ms ou 10ms, há sobrecarga.
• avgqu-sz: Mostra o tamanho médio da fila de pedidos esperando atendimento. Se passar de 3 ou 4, significa que o banco está acumulando requisições em fila.

3. Os parâmetros principais para mudar no my.cnf

A configuração padrão do MySQL vem calibrada para discos antigos e prioriza segurança absoluta sobre velocidade. Em servidores dedicados de alta performance, você pode ajustar estes valores no arquivo /etc/mysql/my.cnf:

[mysqld]
# Grava no log a cada commit mas só sincroniza no disco uma vez por segundo
innodb_flush_log_at_trx_commit = 2

# Ajusta a capacidade de IOPS para o padrão de discos NVMe modernos
innodb_io_capacity = 3000
innodb_io_capacity_max = 6000

# Permite mais threads trabalhando na leitura e escrita do banco
innodb_write_io_threads = 8
innodb_read_io_threads = 8

A mudança de innodb_flush_log_at_trx_commit = 1 para 2 é a que dá maior resultado. O MySQL continua gravando todas as transações na memória do sistema operacional imediatamente, mas só força o disco a travar a sincronização física a cada 1 segundo. Isso costuma derrubar o tempo de resposta em operações de escrita em até 80%.

4. Os riscos reais de mudar a durabilidade das transações

Ao usar innodb_flush_log_at_trx_commit = 2, se o serviço do MySQL cair de forma inesperada, você não perde nada porque os dados já estavam no buffer do sistema operacional. O único risco real acontece se a máquina física sofrer um corte total de energia elétrica: nesse caso extremo, você pode perder até 1 segundo de transações que ainda estavam na memória RAM.

Para 99% das lojas virtuais e portais de conteúdo hospedados em datacenters com nobreaks e redundância de energia, esse risco é muito baixo comparado ao ganho de velocidade que você conquista para todos os visitantes.

5. O que essa lentidão de banco faz com o seu SEO

Quando o banco de dados demora para responder, a primeira métrica que sofre é o TTFB (Time to First Byte). Se o seu servidor leva mais de 600ms só para começar a mandar o HTML, sua nota no Core Web Vitals cai, o Largest Contentful Paint (LCP) estoura e o Googlebot diminui a quantidade de páginas que rastreia por dia no seu site. Ajustar o banco é um dos passos fundamentais da nossa Consultoria de SEO Técnico.

6. Como resolver a velocidade do seu banco de dados

Eu atendo operações digitais que precisam de desempenho alto e estabilidade contínua. Se o seu banco de dados está lento ou travando sob tráfego, fale diretamente comigo para avaliarmos a estrutura do seu servidor.