O Fim do "A culpa é do Banco" (Foco em Linux + Performance)

Todo DBA Sênior já participou daquela clássica "sala de guerra" (War Room). O sistema está lento, os usuários estão reclamando e a primeira frase que se ouve é: "A culpa é do banco de dados, olha lá!".

Você analisa as métricas da sua instância (seja IBM Informix, Oracle ou PostgreSQL) e nota um alto índice de esperas por I/O (I/O Waits). No entanto, a equipe de infraestrutura abre o painel do Storage e afirma categoricamente: "Nosso storage está entregando latência de 1ms, o problema não é aqui".

Como sair desse impasse de "achismos"? A resposta não está no iostat ou no sar. A resposta definitiva está dentro do próprio kernel do Linux, utilizando a tecnologia eBPF.

O que é o eBPF e o bcc-tools?

O eBPF (Extended Berkeley Packet Filter) é uma das maiores revoluções recentes do Linux. Ele permite que você execute programas em um ambiente seguro (sandbox) diretamente dentro do kernel do sistema operacional, sem precisar recompilar o kernel ou carregar módulos perigosos.

Para facilitar a vida dos administradores, foi criado o pacote bcc-tools (BPF Compiler Collection), que traz dezenas de scripts prontos para extrair métricas de performance com precisão de microssegundos, com impacto quase zero na CPU.

Instalando as ferramentas

A instalação é simples e está disponível nos repositórios oficiais das principais distribuições Linux corporativas:

# Em sistemas baseados em Debian/Ubuntu
sudo apt-get update
sudo apt-get install bpfcc-tools linux-headers-$(uname -r)

# Em sistemas baseados em RHEL/CentOS/Oracle Linux
sudo yum install bcc-tools kernel-devel-$(uname -r)

Nota: Dependendo da distribuição, os comandos ganham o sufixo -bpfcc (ex: biolatency-bpfcc).

1. biolatency: O Raio-X do seu Disco

O iostat mostra médias. E médias mentem. Se você tem 99 operações levando 1ms e 1 operação levando 1000ms, a média parecerá aceitável, mas aquela única operação lenta pode estar travando um checkpoint crítico do seu banco de dados.

O comando biolatency rastreia o tempo exato que o dispositivo de bloco (disco) levou para responder ao sistema operacional e gera um histograma visual.

# Medindo a latência de I/O em milissegundos por 10 segundos
sudo biolatency-bpfcc -m 10

Exemplo de Saída:

msecs               : count     distribution
    0 -> 1          : 3245     |****************************************|
    2 -> 3          : 453      |*****                                   |
    4 -> 7          : 12       |                                        |
    8 -> 15         : 3        |                                        |
   16 -> 31         : 0        |                                        |
   32 -> 63         : 0        |                                        |
   64 -> 127        : 1        |                                        |
  128 -> 255        : 150      |**                                      |

Como ler isso na reunião: "Equipe de Infra, a maioria das operações realmente ocorre em 1ms. Porém, observem o pico bimodal no final do histograma. Tivemos 150 operações que levaram entre 128ms e 255ms para serem concluídas no nível do bloco. O gargalo existe e está afetando o banco."

2. ext4slower / xfs_slower: A "Arma Fumegante"

Se o biolatency prova que o disco está lento, as ferramentas da família slower provam quem está sofrendo com isso e qual arquivo está sendo lido ou gravado no momento da lentidão.

Se o seu banco de dados está em um sistema de arquivos XFS, você pode pedir ao kernel para mostrar apenas as operações de I/O que demoraram mais de 10 milissegundos:

# Rastreando operações no XFS mais lentas que 10ms
sudo xfsslower-bpfcc 10

Exemplo de Saída:

TIME     COMM           PID    T BYTES   OFF_KB   LAT(ms) FILENAME
14:32:12 oninit         4512   W 8192    124000     15.23 rootdbs.000
14:32:15 oninit         4512   R 16384   854120     42.10 datadbs1.000
14:32:18 oracle         8921   W 8192    512000     85.50 redo01.log

O xeque-mate: Com esse comando, você entrega o relatório exato. Você mostra o horário, o processo do banco de dados (oninit, oracle, etc.), se era leitura (R) ou gravação (W), a latência exata em milissegundos e, o mais importante, o nome do arquivo físico que sofreu a lentidão (ex: um dbspace ou um redo log).

Conclusão

A administração de bancos de dados de missão crítica exige observabilidade avançada. Quando você para de usar ferramentas baseadas em médias e passa a usar o eBPF para analisar eventos no nível do kernel, o diagnóstico deixa de ser uma opinião e passa a ser um fato matemático.

Se o seu ambiente de banco de dados apresenta lentidões misteriosas, travamentos de aplicação ou picos de I/O inexplicáveis, não tente adivinhar. Meça com as ferramentas certas.