O Raio-X do Linux: Por que o comando 'strace' é a arma secreta dos Sysadmins

Você já passou pela situação de iniciar um serviço, ele falhar silenciosamente, e os arquivos de log em /var/log/ estarem completamente vazios? Ou pior: um processo do banco de dados congela do nada e não consome CPU, ficando em estado de "espera fantasma".

Quando as ferramentas tradicionais falham, os Sysadmins e DBAs seniores recorrem a uma ferramenta que muitos subestimam ou têm medo de usar devido à quantidade de informações que ela gera: o comando strace.

O que é o strace?

O strace (System Call Tracer) é um utilitário de diagnóstico, instrução e depuração no Linux. Ele intercepta e registra as "chamadas de sistema" (system calls) que um processo faz ao Kernel do Linux, bem como os sinais que o processo recebe.

Em termos simples: se um programa tenta abrir um arquivo, ler uma rede, alocar memória ou se conectar a um socket, o strace mostra exatamente o que ele pediu e qual foi a resposta do Kernel (como um erro de "Permissão Negada" ou "Arquivo não encontrado").

Exemplos Práticos de Sobrevivência

A saída padrão do strace pode ser assustadora, mas dominando algumas flags, ele se torna o seu melhor amigo:

• Descobrir por que um processo travou:
  strace -p
  Anexa o strace a um processo que já está rodando. Se ele estiver travado tentando ler um arquivo de rede inacessível, você verá a chamada read() ou connect() pendurada na tela.
• Onde este programa está procurando o arquivo de configuração?
  strace -e trace=open,openat comando_aqui
  Filtra a saída para mostrar apenas as tentativas de abertura de arquivos. Excelente para descobrir qual .conf um serviço obscuro está tentando ler durante a inicialização.
• Seguir processos filhos (Forks):
  strace -f -p
  Muitos serviços (como Apache, Nginx ou bancos de dados) criam processos filhos. A flag -f garante que o strace acompanhe todos eles, não apenas o processo pai.
• Criar um relatório de gargalos (Profiling):
  strace -c -p
  Em vez de mostrar um fluxo infinito de texto, a flag -c conta o tempo gasto em cada chamada de sistema e exibe uma tabela limpa no final. Perfeito para descobrir se a lentidão do seu banco de dados é culpa de I/O de disco ou de rede.

O Caso Clássico do "Permission Denied" Invisível

Imagine que um script falha, mas não diz o porquê. Rodando strace ./seu_script.sh, você pode procurar na saída por algo como EACCES (Permission denied). O strace revelará o caminho exato do arquivo ou diretório que está bloqueando a execução, permitindo que você corrija o chmod ou chown cirurgicamente, sem precisar dar permissão 777 para tudo.

Troubleshooting no nível do Kernel

Não dependa de adivinhações quando um sistema crítico falha. O uso de ferramentas de baixo nível como o strace é o que garante diagnósticos precisos e rápidos. Na AJMSolutions, utilizamos as técnicas mais avançadas de depuração do Linux para manter a performance e a estabilidade dos seus ambientes de banco de dados.

Maximizando a Performance do IBM Informix em Servidores Multi-Core com Afinidade de CPU e NUMA

Quando migramos bancos de dados de missão crítica para servidores modernos de grande porte, um erro comum é acreditar que "mais CPUs" significa automaticamente "mais performance". Na realidade, sem a configuração correta, adicionar processadores pode até piorar o desempenho do seu IBM Informix.

O grande vilão invisível em servidores multi-core modernos chama-se Latência NUMA (Non-Uniform Memory Access). Neste artigo, vamos entender como a Afinidade de CPU (CPU Affinity) no Informix pode resolver esse problema e extrair 100% do poder do seu hardware.

O Problema da Arquitetura NUMA

Em servidores com múltiplos processadores físicos (sockets), a memória RAM é dividida e conectada diretamente a cada processador. Isso cria os chamados "Nós NUMA".

Se uma thread do Informix (um Virtual Processor - VP) está rodando na CPU do Nó 0, mas precisa acessar dados que estão na memória RAM conectada ao Nó 1, ocorre o Cross-Node Memory Access. Esse tráfego passa pelo barramento de interconexão da placa-mãe, gerando latência e destruindo a performance de consultas pesadas.

Mapeando a Topologia do Servidor (Linux)

Antes de configurar o banco, precisamos entender o hardware. Vamos usar como exemplo um servidor robusto com 96 CPUs lógicas (2 sockets, 24 cores físicos por socket, com Hyper-Threading habilitado).

O primeiro passo é rodar o comando lscpu no Linux para mapear quais CPUs pertencem a quais nós NUMA:

# Verificando a topologia NUMA no Linux
lscpu | grep NUMA

Exemplo de Saída:

NUMA node(s):          2
NUMA node0 CPU(s):     0-23,48-71
NUMA node1 CPU(s):     24-47,72-95

Neste cenário, sabemos exatamente quais IDs de CPU pertencem a cada processador físico. Também sabemos que as CPUs de 48 a 95 são threads virtuais (Hyper-Threading), que geralmente evitamos para os VPs principais de CPU do banco de dados para garantir ciclos de clock dedicados.

Configurando a Afinidade no Informix (onconfig)

O IBM Informix (especialmente nas versões mais recentes, como a 14.10) possui um controle granular excelente sobre onde seus Virtual Processors vão rodar. Isso é feito através do parâmetro VPCLASS no arquivo onconfig.

Em vez de deixar o sistema operacional (Linux) jogar os processos do Informix de um lado para o outro (causando context switching e perda de cache L3), nós "amarramos" (pin) os VPs a CPUs específicas.

Exemplo Prático de Configuração:
Vamos alocar 24 VPs de CPU para o Informix, distribuindo a carga de forma inteligente e usando apenas núcleos físicos reais. Vamos definir a afinidade para usar as CPUs de 0 a 11 (Nó 0) e de 24 a 35 (Nó 1).

# Configuração no arquivo onconfig
# num=24 : Cria 24 Virtual Processors da classe CPU
# aff=(0-11,24-35) : Amarra os VPs aos núcleos físicos específicos
VPCLASS cpu,num=24,aff=(0-11,24-35)

Por que essa configuração é um divisor de águas?

1. Isolamento de Cache L3: Como o VP do Informix nunca muda de CPU, os dados que ele processa permanecem quentes no cache L3 do processador, acelerando leituras subsequentes.
2. Redução de Context Switching: O Linux não gasta recursos tentando balancear os processos do banco de dados entre os núcleos.
3. Previsibilidade: Em ambientes de alta concorrência, você garante que o Informix sempre terá aqueles 24 núcleos físicos dedicados a ele, imunes a picos de processamento de outras aplicações (como agentes de backup ou monitoramento).

Conclusão

Afinidade de CPU não é "micro-otimização", é arquitetura básica para servidores de grande porte. Se você roda IBM Informix em máquinas com dezenas de núcleos e não configurou o parâmetro aff= no seu VPCLASS, seu banco de dados está deixando performance na mesa.

Sempre mapeie sua topologia com lscpu, isole os núcleos físicos dos lógicos (HT) e amarre seus VPs. O tempo de resposta das suas queries vai agradecer.

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.

Comandos Linux: explorando memória virtual com vmstat

 Uma visão detalhada do comando vmstat, sua sintaxe básica e como usá-lo.

Há muitos comandos, ferramentas e variações dos dois para você colocar em prática quando se trata de estatísticas do sistema no Linux. No entanto, se você precisa de detalhes sobre memória virtual, usar o vmstat é uma ótima opção.

O que é?

O Virtual Memory Statistics Reporter, também conhecido como vmstat, é uma ferramenta de linha de comando do Linux que relata vários bits de informações do sistema. O VMSTAT relata informações sobre processos, memória, paginação, bloco de I/O, traps, discos e atividade da CPU.

Ao executar o vmstat, tenha em mente que as informações são uma média  solicitadas desde o momento da última reinicialização. Relatórios subsequentes usam medições de atraso e contagem. Eu abordo esses especificamente durante a discussão de sintaxe.

Sintaxe do comando

A sintaxe do comando vmstat é bem simples:

$ vmstat [option][delay [count]]

Opções

delay - O delay entre a atualização em segundos. Se o delay não é especificado,  um relatório é impresso com os valores médios desde a última inicialização.

count - Números de atualizações. Na ausência de count, quando o delay é definido, o padrão é infinito.

-a, --active

Exibe a memória ativa ou inativa. 

-f, --forks

O -f exibe o número de foros desde a inicialização. Isso inclui as sytem calls, fork, vfork e é equivalente ao número total de tarefas criadas. Cada processos é representado por uma ou mais tarefas, dependendo do uso do thread. Esta tela não se repete.

-m, --slabs

Exibe o slabinfo.

-n, --one-header

 Exibe o cabeçalho apenas uma vez e não periodicamente.

-s, --stats

Mostra uma tabela de vários contadores de eventos e estatísticas de memória. Esta tela não se repete. 

-d, --disk

Relatório de estatísticas de disco.

-D, --disk-sum

Relata algumas estatísticas resumidas sobre a atividade do disco 

-p, --partition device 

Estatísticas detalhadas sobre as partições.

-s, --unit character 

Altera a saida entre 1000 (k), 1024 (K), 1000000 (m), ou 1048576 (M) bytes. Observe que isso não altera os campos do swap (si/so) ou block (bi/bo).

-t, --timestamp

 Adiciona timestamp para cada linha

-w, --wide

Modo de saída amplo (útil para sistema com maior quantidade de memória, onde o modo de saída padrão sofre de quebra de coluna indesejada). A saída é mais larga que 80 caracteres por linha.

-y, --no-first

 Omite o primeiro relatório com estatísticas desde a inicialização do sistema.

-V, --version

Mostra informação sobre a versão e sai.

-h, --help

 Mostra ajuda e sai.  

Saída básica e como entendê-la:

A forma mais básica deste comando não usa nenhuma opção. Aqui está a saída padrão e como lê-la:

Você vê informações sobre processos, memória, swap, IO, sistema e CPU. A página man para o comando declara o seguinte (man vmstat):

• procs
• r: Número de processos em execução (run queue)
• b: Número de processos em espera (blocked)
• memory (são afetados pela opção --unit)
• swpd: Quantidade de memória virtual usada
• free: Memória livre.
• buff: Memória usada como buffer
• cache: Memória usada como cache
• inact: a quantidade de memória inativa. (opção -a)
• active: a quantidade de memória ativa. (opção -a)
• swap (são afetados pela opção --unit)
• si: Quantidade de memória trocada do disco para a RAM (/s).
• so: Quantidade de memória trocada da RAM para o disco (/s).
• io
• bi: Blocos recebidos do dispositivo de bloco (disco) (KiB/s)
• bo: Blocos enviados para o dispositivo de bloco. (KiB/s)
• system
• in: número de interrupções por segundo, incluindo o clock
• cs: número de alteração de contexto por segundo
• cpu (Essas são porcentagens do tempo total da CPU)
• us: tempo gasto executando código não-kernel. (Tempo do usuário, incluindo tempos bons)
• sy: tempo gasto executando o código do kernel. (tempo do sistema)
• id: tempo gasto ocioso. Antes do Linux 2.5.41, isso inclui o tempo io-wait.
• wa: tempo gasto esperando por I/O. 
• st: tempo roubado de uma máquina virtual. Antes do Linux 2.6.11, desconhecido.
• gu: tempo gasto rodando codigo do KVM guest.

Descrição do campo para o modo disco

• Reads
• total: total de leituras completadas com sucesso
• merged: leituras agrupadas (resultando em um I/O)
• sectors: leituras de setor com sucesso
• ms: milissegundos gasto com leituras
• Writes
• total: total de escritas completadas com sucesso
• merged: escritas agrupadas (resultando em um I/O)
• sectors: leituras de setor com sucesso
• ms: milissegundos gasto com escrita
• IO
• cur: I/O em progresso
• s: segundos gastos com I/O

Descrição de campos para modo de partições de disco

• reads: numero total de leituras para essa partição
• read sectors: total de setor lidos para essa partição
• writes: numero total de escrita para essa partição
• requested writes: numero total de requisição de escrita para a partição

Descrição de campos para o modo SLAB

O modo slab mostra estatísticas por slab, para obter mais informações sobre essas informações, consulte Slabinfo (5)

• cache: nome do cache
• num: numeros concorrentes de objetos ativos
• total: números totais de objetos disponíveis
• size: tamanho de cada objeto
• pages: numero de paginas com pelo menos um objeto ativo

Notas

vmstat requer acesso de leitura para os arquivos abaixo de /proc. O -m requer acesso de leitura a /proc/slabinfo, que pode não estar disponível para usuários padrão. Opções de montagem para /proc, como sub-SET = PID, também podem afetar o que é visível.

Identificação de Gargalos

Para identificar gargalos, observe as seguintes situações:

1. CPU:
1. Se us e sy estão altos, a CPU está sobrecarregada.
2. Se wa está alto, há um gargalo de I/O.
2. Memória:
1. Se free está baixo e si/so estão altos, há falta de memória física, causando troca excessiva (swap).
3. Disco:
1. Se bi e bo estão altos, há muita atividade de disco, indicando um possível gargalo de I/O.