Resumir o tempo gasto em chamadas de sistema com strace -c, seu overhead e o perf trace como alternativa

Objetivo

Obter um resumo ordenado das chamadas de sistema em que um processo gasta tempo, em vez de um trace ao vivo que rola na tela, e saber quando o próprio rastreamento passa a ser o gargalo.

Pré-requisitos

O pacote strace. Rastrear um comando que você mesmo inicia (strace -c <command>) não exige nenhum privilégio extra; anexar-se a um processo em execução com -p exige root ou CAP_SYS_PTRACE, a menos que a configuração Yama kernel.yama.ptrace_scope permita (no valor comum 1, um usuário sem privilégios só pode se anexar aos seus próprios descendentes). O perf, caso a alternativa do passo 4 seja necessária.

Passos

1. Anexe-se por um tempo limitado e depois desanexe, por exemplo com timeout 20 strace -c -f -p <pid>; sem -f, o -p anexa apenas à única thread cujo ID é <pid>, e as threads de trabalho de um servidor multithread ficam de fora. O manual do strace descreve -c/--summary-only como a opção que contabiliza tempo, chamadas e erros de cada chamada de sistema e informa um resumo ao sair, suprimindo a saída normal por chamada — a visão agregada de que uma pergunta do tipo “qual syscall domina” precisa — e observa que isso mostra o tempo de sistema (tempo de CPU do kernel), independente do tempo de relógio (wall-clock).
2. Leia primeiro o resumo ordenado pelo percentual de tempo. Como a medida padrão é o tempo de CPU do kernel, chamadas que passam a maior parte do tempo bloqueadas (futex, epoll_wait, um read em socket) parecem baratas nele; acrescente -w/--summary-wall-clock para ordenar as chamadas pelo tempo de relógio, da entrada à saída, quando a pergunta é onde o processo espera. Muito tempo em futex ou epoll_wait aponta então para contenção ou espera ociosa, e em read/write, para I/O.
3. Conheça o custo antes de confiar nos números: o manual do strace afirma claramente que um processo rastreado roda mais devagar que um não rastreado e que o impacto no desempenho pode ser reduzido com a opção --seccomp-bpf. Essa opção só tem efeito junto com -f, não se aplica a processos anexados com -p e só evita paradas quando apenas um subconjunto das chamadas é rastreado (-e trace=...); portanto, não ajuda no caso de anexar e contar descrito acima. Para um processo sensível à latência, esse overhead pode alterar o próprio comportamento observado.
4. Quando esse overhead importa, use o perf trace. O manual o apresenta como uma ferramenta inspirada no strace que relata o mesmo tipo de atividade de syscalls e eventos do sistema, ao vivo ou a partir de uma sessão gravada antes com perf record, construída sobre a infraestrutura de tracepoints/perf_events do kernel em vez do ptrace. Experimente perf trace -p <pid> para uma visão ao vivo, ou perf trace -s -p <pid> para um resumo por thread com tempos mínimo, médio e máximo; normalmente exige root.
5. Não presuma uma diferença percentual fixa entre as duas ferramentas sem medir na carga de trabalho real; nenhum dos dois manuais indica um valor numérico de overhead, e o custo relativo depende de quanto a carga faz uso intenso de syscalls.

Resultado esperado

Uma lista ordenada de quais chamadas de sistema consumiram mais tempo e com que frequência foram chamadas, obtida sem um trace completo linha a linha, além de uma escolha fundamentada entre a simplicidade do strace -c e o perfil de overhead diferente do perf trace.

Limites e base de verificação

As duas ferramentas só enxergam a atividade depois de se anexarem; um pico anterior passa despercebido. O -f/--follow-forks é necessário para contar também as chamadas dos processos filhos e, com -p, as das demais threads. Desanexe logo após capturar o resumo, pois o overhead se aplica durante todo o tempo em que o processo está anexado, e não apenas enquanto a saída está sendo lida.