Latência ou throughput: por que seu banco de dados ignora a velocidade da rede

Você já recebeu aquele chamado às 3 da manhã: "O banco está travado, a aplicação não responde". Você abre o painel de monitoramento, preparado para ver os discos pegando fogo, e encontra... nada. O throughput está em ridículos 50 MB/s, a rede está ociosa e a CPU está dormindo. No entanto, o iowait está alto e as transações estão empilhando.

O gerente de infraestrutura sugere dobrar a largura de banda da rede ou migrar para discos com maior taxa de transferência sequencial. Se você aceitar essa sugestão, estará apenas queimando orçamento.

O problema é que a maioria dos profissionais de TI trata bancos de dados como se fossem servidores de arquivos. Eles olham para a especificação de "7.000 MB/s" na caixa de um NVMe e assumem que o banco de dados vai voar. Não vai. Bancos de dados transacionais (OLTP) não se importam com quantos gigabytes você consegue mover por segundo; eles se importam com quanto tempo leva para mover um único bloco de 4KB e receber a confirmação de que ele está seguro.

Resumo em 30 segundos

• Throughput é vaidade, Latência é sanidade: Em cargas de trabalho OLTP, a velocidade máxima de transferência (MB/s) é irrelevante se o tempo de resposta (latência) de cada operação individual for alto.
• A física do acesso aleatório: Bancos de dados leem e escrevem pequenos blocos de dados (4KB a 16KB) de forma aleatória, o que expõe as limitações físicas e de protocolo do armazenamento, ignorando as métricas de marketing de leitura sequencial.
• O gargalo da serialização: Operações ACID exigem confirmação de gravação (fsync). Se o seu disco leva 1ms para confirmar um dado, você está matematicamente limitado a 1.000 operações por segundo por thread, não importa se o link é de 100GbE.

O paradoxo do disco ocioso com aplicação travada

A confusão começa na definição de performance. Para um servidor de streaming de vídeo, performance é Throughput (vazão): a capacidade de empurrar um grande volume de dados continuamente. Para um banco de dados como PostgreSQL, MySQL ou Oracle em regime transacional, performance é IOPS em baixa latência.

Imagine uma rodovia. O throughput é o número de faixas (largura da banda). A latência é o limite de velocidade e a qualidade do asfalto. Se você tem um caminhão (uma query complexa de OLAP), ter 10 faixas ajuda muito. Mas se você tem 10.000 motoboys (transações pequenas) que precisam ir do ponto A ao ponto B, parar, pegar uma assinatura e voltar, o que importa não é a largura da estrada, mas sim a velocidade com que eles conseguem fazer o retorno.

Figura: Comparação visual: A largura da via (Throughput) versus a velocidade de tráfego individual (Latência).

Quando você vê um disco "ocioso" em MB/s mas com a aplicação lenta, você está testemunhando o fenômeno de Queue Depth (QD) starvation causado por latência. Se sua aplicação é single-threaded ou tem dependências seriais, ela envia uma requisição de I/O e para. Ela não envia a próxima até que o disco diga "pronto".

💡 Dica Pro: Use a Lei de Little aplicada ao Storage. IOPS = Queue Depth / Latência. Se sua latência é 5ms (0,005s) e sua aplicação opera com QD=1 (serial), seu teto máximo teórico é 200 IOPS. Você pode ter um array All-Flash capaz de 1 milhão de IOPS; você só vai usar 200.

A física do acesso aleatório de 4k versus sequencial

Fabricantes de SSD adoram estampar números sequenciais nas caixas. "Leitura de até 7.400 MB/s!". Isso é ótimo para copiar ISOs ou carregar texturas de jogos. Para um banco de dados, isso é ruído.

O padrão de acesso de um banco de dados é ditado pelo tamanho da sua página (page size). No PostgreSQL padrão, isso é 8KB. No MySQL (InnoDB), 16KB. Quando você faz um SELECT * FROM users WHERE id = 405, o banco não lê o arquivo inteiro. Ele busca um ponteiro no índice e vai buscar exatamente aquela página específica no meio do arquivo de dados. Isso é I/O Aleatório.

Em discos mecânicos (HDD), isso envolvia mover fisicamente a cabeça de leitura (seek time), o que levava milissegundos preciosos. Em SSDs e NVMe, eliminamos a parte mecânica, mas não eliminamos o overhead do protocolo e da controladora NAND.

Um SSD Enterprise moderno pode ter uma latência de leitura de 80 microssegundos (0,08ms). Um SSD de consumidor barato (QLC, sem DRAM cache) pode ter picos de 2ms ou mais sob carga. Essa diferença de "apenas" 2 milissegundos é a diferença entre um banco que responde instantaneamente e um que causa timeouts na aplicação.

⚠️ Perigo: Nunca use SSDs QLC (Quad-Level Cell) para bancos de dados de produção. A latência de escrita após o esgotamento do cache SLC é catastrófica, podendo chegar a segundos, o que causará o congelamento total do banco de dados durante o checkpoint.

O erro de escalar largura de banda para resolver esperas de I/O

É comum ver arquitetos tentando resolver problemas de latência de disco aumentando a rede de armazenamento (SAN/NAS) de 10GbE para 25GbE ou 100GbE. Isso raramente funciona para cargas OLTP.

A latência de rede é composta por:

1. Processamento do Host (Kernel/Driver): Tempo para empacotar o comando SCSI/NVMe.

2. Serialização na Placa de Rede: Tempo para colocar os bits no fio.

3. Tempo de Voo (Física): Luz na fibra.

4. Processamento no Storage: Tempo para o array receber, processar e comitar no disco.

Aumentar a largura de banda (10GbE -> 100GbE) melhora apenas o item 2, e apenas marginalmente para pacotes pequenos de 4KB ou 8KB. O tempo de serialização de um pacote de 4KB em 10GbE já é irrelevante (nanossegundos). O gargalo real geralmente está no item 4 (latência da mídia) ou no item 1 (overhead de software).

Figura: Decomposição da latência de I/O: Note como a largura de banda da rede afeta apenas uma fração ínfima do tempo total de uma transação de banco de dados.

Se o seu storage array demora 1ms para confirmar uma escrita (Ack), sua rede pode ser infinita que o banco continuará lento. É por isso que tecnologias como NVMe-oF (NVMe over Fabrics) e RDMA (Remote Direct Memory Access) são revolucionárias. Elas não aumentam apenas a banda; elas removem o kernel do caminho e reduzem a latência drasticamente, aproximando o storage remoto da performance de um disco local.

Mapeando o perfil de I/O da aplicação para a mídia correta

Não existe "o melhor disco". Existe o disco certo para o perfil de I/O. Como DBA ou Arquiteto de Storage, você precisa categorizar a carga:

1. O Log de Transação (WAL/Redo Log)

Este é o componente mais crítico. Todo INSERT, UPDATE ou DELETE gera uma escrita aqui antes de qualquer coisa.

• Perfil: Escrita Sequencial, Síncrona (O_DSYNC ou fsync), Tamanho de bloco variável (geralmente pequeno).

• Exigência: Latência de escrita ultra-baixa.

• Solução Ideal: Discos Optane (se ainda encontrar), NVMe Enterprise de alta resistência (DWPD > 3) ou SSDs SLC. Espelhamento (RAID 1/10) é obrigatório.

• O que mata a performance: Latência de commit. Se o disco demora, a transação segura o lock no banco, travando todos os outros usuários.

2. Data Files (Tablespaces)

Onde os dados residem.

• Perfil: Leitura Aleatória (Random Read) dominante, Escrita Aleatória (durante Checkpoints).

• Exigência: IOPS Aleatório alto (Random Read 4K IOPS).

• Solução Ideal: NVMe TLC Enterprise.

• O que mata a performance: Baixo IOPS em Queue Depth baixo.

3. TempDB / Sort Area

Onde o banco faz ordenações que não cabem na RAM.

• Perfil: Misto, mas com surtos de escrita e leitura sequencial e aleatória.

• Exigência: Throughput e IOPS.

• Solução Ideal: Pode ser discos com menor durabilidade, mas rápidos. Em muitos casos, discos locais efêmeros em nuvem são perfeitos aqui.

Métricas de validação além dos gigabytes por segundo

Pare de olhar para o htop ou Task Manager e ver "Disk Usage". Isso não diz nada. Para diagnosticar problemas de storage em bancos de dados, você precisa de métricas de latência.

No Linux, a ferramenta iostat (do pacote sysstat) é sua melhor amiga, mas você precisa saber ler as colunas certas:

• r_await e w_await: O tempo médio (em milissegundos) que as requisições de leitura e escrita esperaram na fila E foram atendidas pelo disco.

  • Bom: < 1ms (NVMe), < 5ms (SSD SATA).
  • Preocupante: > 10ms.
  • Crítico: > 20ms (O banco vai começar a reclamar).

• avgrq-sz: Tamanho médio da requisição em setores (512 bytes). Isso te diz se o banco está fazendo I/O sequencial (números grandes) ou aleatório (números pequenos, perto de 8 ou 16 setores).

• %util: Útil, mas enganoso em RAIDs ou SSDs modernos. 100% de utilização não significa necessariamente que o disco não aguenta mais, apenas que ele tem sempre algo na fila. Com NVMe, você pode estar em 100% de util e ainda ter baixa latência.

Figura: A mentira da média: Um mapa de calor de latência revela os picos de 'latência de cauda' (tail latency) que as médias escondem, mas que o usuário sente.

Como vemos na imagem acima, a média é uma mentira. Um disco pode ter média de 2ms, mas se a cada 100 requisições uma leva 200ms (latência de cauda), seu banco de dados terá "engasgos" perceptíveis. Monitore sempre o P95 e P99 da latência de disco.

Alerta Final

Não caia na armadilha de resolver problemas de banco de dados jogando hardware genérico no problema. Um banco de dados travado em um storage array de 100.000 IOPS é uma cena comum quando o gargalo é a latência de uma única thread aguardando um fsync.

Antes de assinar o cheque para a nova SAN All-Flash ou para as placas de rede de 100Gb, faça a lição de casa:

1. Meça a latência de disco atual (await) durante o pico de carga.

2. Verifique se o gargalo é leitura (falta de RAM/Cache) ou escrita (Log/WAL lento).

3. Entenda que para bancos de dados, 1ms de latência vale mais que 10 GB/s de throughput.

Se você ignorar a física do acesso aleatório, seu banco de dados continuará ignorando a velocidade da sua rede.

Referências & Leitura Complementar

• SNIA (Storage Networking Industry Association): "Understanding SSD Latency Outliers". Whitepaper técnico sobre como a latência de cauda afeta aplicações.

• PostgreSQL Documentation: "WAL Configuration & Reliability". Detalhes sobre fsync, open_datasync e o impacto no hardware de armazenamento.

• NVM Express Base Specification 2.0: Seções sobre Namespaces, Arbitration e Command Handling para entender como o NVMe trata filas.

• Gregg, Brendan: "Systems Performance: Enterprise and the Cloud". Leitura obrigatória para entender a metodologia USE (Utilization, Saturation, Errors).