strace e perf para resolução de problemas no Linux

Quando um servidor Linux está lento, a falhar ou a sobrecarregar a CPU e os registos da aplicação não explicam o motivo, duas ferramentas cobrem a maior parte das lacunas. strace indica o que um processo está a solicitar ao kernel. perf indica onde a CPU está a gastar o seu tempo. Juntas, respondem às perguntas «por que está bloqueado» e «o que está a fazer», que nada mais resolve de forma tão económica.

Este artigo aborda quando recorrer a cada ferramenta, como instalá-las, os comandos que irá efetivamente executar e como manter a sobrecarga controlável num servidor em produção.

Quando usar strace vs perf

A diferença é simples. Use perf quando a CPU estiver ocupada e precisar de saber qual a função responsável. Use strace quando um processo estiver a bloquear, a falhar, a devolver erros estranhos ou a comportar-se de uma forma que os registos não explicam.

perf O strace recolhe amostras dos contadores de hardware do kernel a uma frequência configurável, pelo que a sobrecarga é normalmente inferior a 1% e é seguro executá-lo em produção. strace intercepta todas as chamadas de sistema através de ptrace, o que pode tornar o processo alvo 10 a 100 vezes mais lento. Use-o com moderação em sistemas ativos e sempre com filtros.

Instalação do strace e do perf

Ambas as ferramentas encontram-se nos repositórios padrão. O strace baseia-se na ptrace syscall, que faz parte de todos os kernels modernos há anos. O perf utiliza a perf_events interface e necessita de um pacote compatível com o seu kernel em execução.

No Ubuntu ou Debian:

sudo apt install strace linux-tools-common linux-tools-$(uname -r)

No RHEL, AlmaLinux ou Fedora:

sudo dnf install strace perf

O $(uname -r) versão do kernel é importante. Um binário perf compilado para uma versão diferente do kernel produz resultados confusos e pode ignorar eventos silenciosamente. Verifique com perf --version e strace -V após a instalação.

Para que o perf mostre nomes de funções em vez de endereços hexadecimais, são necessários símbolos de depuração. Instale o -dbg ou -debuginfo (por exemplo, libc6-dbg no Debian) e compile os seus próprios binários com -g no GCC.

Dentro de contentores, strace é necessário --cap-add=SYS_PTRACE e perf necessidades --cap-add=SYS_ADMIN ao iniciar com o Docker. Sem estes limites, as ferramentas falham de formas que parecem erros.

Rastrear chamadas de sistema com o strace

A execução do strace command rastreia um processo desde o seu início. Para se ligar a um processo em execução, utilize strace -p PID. Para qualquer processo multithread ou que crie processos filhos, adicione -f para acompanhar os processos filhos, ou perderá a maior parte da atividade.

As linhas de saída terminam com um valor de retorno. -1 ENOENT significa que o ficheiro solicitado pelo processo não existe. -1 EACCES significa permissões. Esses dois erros, por si só, são responsáveis por uma parte surpreendente dos bugs de produção.

O sinalizador mais útil é -e trace=GROUP, que limita a saída a uma categoria de chamadas de sistema nomeada e mantém o ruído controlável.

Num servidor ocupado, comece com strace -c -p PID durante dez ou vinte segundos. A -c flag imprime um resumo das contagens de chamadas de sistema, tempo total e erros quando se desliga. Isso indica-lhe qual a categoria que vale a pena analisar mais de perto sem sobrecarregar o terminal. Em seguida, volte a ligar com um filtro restrito.

Outros sinalizadores que vale a pena conhecer: -T regista o tempo gasto em cada chamada, -Z mostra apenas chamadas com falha e -o file grava num registo em vez de no terminal, o que é muito mais rápido num processo ruidoso.

Análise do desempenho da CPU com o perf

O perf tem quatro comandos que irá utilizar na maioria das vezes.

Comece por perf stat -p PID para uma visão geral rápida. Os números a ter em conta:

• IPC (instruções por ciclo) abaixo de 1,0: a CPU está a ficar parada, geralmente devido ao acesso à memória.
• Elevado número de falhas de carga LLC: o conjunto de trabalho não cabe na cache, pelo que a CPU está à espera da RAM.
• Contagem elevada de trocas de contexto: típico de cargas de trabalho limitadas por E/S, em que os threads ficam bloqueados no disco ou na rede.

Se algo parecer errado, verifique perf record -F 99 -g -p PID -- sleep 30. As -F 99 amostras a 99 Hz, o que é suficiente para encontrar funções ativas e evita a sincronização com o temporizador do kernel em números redondos como 100 Hz. O -g flag captura gráficos de chamadas, pelo que perf report possa mostrar quais os caminhos de entrada numa função que são responsáveis.

Na perf report, a coluna Overhead representa a percentagem do total de amostras. Um overhead elevado em _int_malloc ou memcpy significa uma alocação pesada. Uma sobrecarga elevada numa das suas próprias funções é o ponto crítico que procurava.

Se vir endereços hexadecimais em vez de nomes de funções, o binário está desmontado ou faltam símbolos de depuração. Instale o -dbg ou recompile o binário com -g.

Um fluxo de trabalho prático num servidor ativo

Para um incidente real num servidor em pleno funcionamento, a rotina é a seguinte:

1. Confirme primeiro o sintoma com ferramentas simples: top, vmstat, iostat. Se estiver numa VM, verifique a st coluna (steal). Qualquer valor acima de 5% significa que o hipervisor é o gargalo, não o seu código.
2. Se a CPU estiver elevada, execute perf top durante alguns segundos e, em seguida, perf record -F 99 -g -p PID -- sleep 30 para o processo em questão. Uma captura de 30 segundos a 99 Hz produz cerca de 1,7 MB de dados.
3. Se o processo estiver travado, lento ou a devolver erros, execute strace -c -p PID durante dez segundos e leia o resumo. Se uma categoria de chamadas de sistema dominar, restrinja com strace -e trace=GROUP -T -p PID.
4. Quando encontrar a chamada de sistema ou função suspeita, desligue. Não deixe nenhuma das ferramentas a funcionar em produção por mais tempo do que o necessário.

Duas advertências. strace A saída pode incluir variáveis de ambiente, caminhos de ficheiros e bytes lidos de sockets, por isso limpe os registos antes de os partilhar fora da sua equipa. E se vai fazer isto regularmente, considere bpftrace e ao conjunto de ferramentas eBPF mais abrangente como próximo passo: o mesmo tipo de visibilidade, sobrecarga inferior a 1%, concebido para produção desde o início.

Se executa cargas de trabalho em que o acesso a diagnósticos aprofundados é importante e a infraestrutura partilhada não é uma opção, consulte os nossos servidores dedicados.