PIDSTAT Linux: Analisar o consumo de CPU e de memória de processos individuais

Com pidstat No Linux, medo a atividade da CPU, da memória, das E/S e dos threads por cada processo em intervalos fixos, o que me permite identificar tendências em vez de instantâneos. É assim que descubro Estrangulamentos de forma fiável, atribui-as a um PID ou a um comando e determina se a causa é a CPU, a RAM, a E/S ou uma mudança de contexto.

Pontos centrais

• Medição por intervalos: Séries temporais por processo, em vez de um mero instantâneo.
• Ampla cobertura: CPU, memória, E/S, threads e mudanças de contexto.
• Filtragem seletiva: Observar com foco, através de PID ou comando.
• Fácil de utilizar: instalar o sysstat e iniciá-lo diretamente.
• Vantagens práticas: Identificar rapidamente picos de carga, fugas e estrangulamentos de E/S.

O que é o pidstat? Uma explicação sucinta

Eu uso pidstat, para visualizar a utilização de recursos por cada processo ao longo do tempo. A ferramenta faz parte do pacote sysstat e fornece, para cada processo, dados relativos à CPU, à memória, às E/S, aos threads e às mudanças de contexto. Ao contrário do `top`, não obtenho uma visão momentânea, mas sim pontos de medição contínuos em intervalos. Isso permite-me identificar padrões como picos periódicos, carga contínua ou crescimento gradual. Esta informação temporal ajuda-me a atribuir claramente as causas a um processo e a não me perder no ruído de um instantâneo.

Instalação e colocação rápida em funcionamento

Eu instalo sysstat com o gestor de pacotes da minha distribuição e inicio o pidstat imediatamente, sem necessidade de configuração adicional. A sintaxe básica continua a ser simples: pidstat [opções] [intervalo] [número]. Sem opções, a ferramenta mostra CPU-Valores por processo; repete as medições de forma contínua, com um intervalo. Exemplo: pidstat 2 10 Recolhe dez registos a cada dois segundos. É assim que consigo criar rapidamente uma linha temporal fiável para análise posterior.

Análise da CPU: visualizar a carga por processo

Para questões relacionadas com a CPU, começo por... pidstat com -u, por exemplo pidstat -u 1 para o contador de segundos. As colunas %usr, %system e %CPU mostram-me quanto tempo de utilizador e de kernel um processo consome. Se precisar de me concentrar numa aplicação, utilizo -p ou -C para filtros de nomes. Se o %system aumentar significativamente, verifico as chamadas de sistema ou os impactos de E/S; se o %usr for predominante, o trabalho está no espaço do utilizador. Para uma análise mais aprofundada por processo, remeto, se necessário, para Contabilidade de processos, para analisar os dados de utilização de forma estruturada.

Verificar de forma específica o consumo de memória

No que diz respeito a temas relacionados com a RAM, a empresa oferece -r informações valiosas, por exemplo, com pidstat -r -p 1234 1. Observo a evolução da memória virtualmente ocupada e da memória residente ao longo de alguns minutos e verifico se as falhas de página aumentam. Se o consumo aumentar de forma constante, em pequenos incrementos, consigo detetar possíveis fugas numa fase precoce. Se a procura se mantiver constante e apenas aumentar em fases curtas, isso indica uma utilização legítima Armazenamento em cache . Através da medição por intervalos, consigo distinguir claramente os valores atípicos das tendências reais.

Compreender a E/S e a mudança de contexto

Com -d mostro a atividade de leitura e escrita por processo e, assim, identifico as causas dos tempos de espera elevados no suporte de dados. Taxas de transferência elevadas, combinadas com latências crescentes, sugerem a existência de estrangulamentos no armazenamento. Além disso, verifico com -w as mudanças de contexto por segundo, porque mudanças excessivas podem gerar sobrecarga desnecessária. Um número elevado de mudanças voluntárias (vswch/s) indica sincronização; um número elevado de mudanças forçadas (cswch/s) indica uma forte competição pelo tempo de CPU. É assim que identifico cargas de trabalho ineficientes, que procuro resolver de forma específica.

Monitorizar threads e identificar pontos críticos

Devo utilizar -t, o pidstat fornece, adicionalmente, valores relativos aos threads por cada processo. Isso permite-me verificar se determinados workers de uma aplicação estão a sair do normal. No caso do Java, do PHP-FPM, das bases de dados ou dos workers de filas, consigo assim identificar threads que estão a sobrecarregar a CPU ou a aumentar o consumo de memória. Se detetar desequilíbrios, ajusto os conjuntos de threads, as afinidades ou Limites . Esta perspetiva ajuda-me a otimizar não só os processos, mas também o seu paralelismo interno.

Visão geral das opções importantes

Utilizo os interruptores principais de forma específica para Análises conduzir de forma focada e manter as saídas legíveis. A tabela seguinte resume de forma concisa as opções principais e as utilizações típicas. Assim, consigo selecionar rapidamente o comutador adequado para a CPU, a memória, as E/S, os threads ou os filtros. Os exemplos ajudam-me a começar sem rodeios. Cada linha fornece-me uma visão clara Nota de acordo com a finalidade de utilização.

Opção	Função	Exemplo
-u	Mostrar a utilização da CPU por processo	pidstat -u 1
-r	Valores de falhas de memória e de página	pidstat -r -p 1234 2
-d	Atividade de E/S de leitura/gravação	pidstat -d 1
-w	Mudança de contexto por processo	pidstat -w -p 1234 1
-t	Mostrar estatísticas do tópico	pidstat -t -p 1234 1
-p	Limitar a um ID de processo específico	pidstat -u -p 1234 1
-C	Filtrar processos por comando	pidstat -C php-fpm 2

Filtros, intervalos e monitorização específica

Estou a planear realizar medições com Intervalos, que se adequam à questão: segundos para os atletas de provas de velocidade, minutos para os de provas de longa distância. Sobre -p e -C reduzo a saída aos processos relevantes e mantenho a consola organizada. pidstat 2 10 É ideal para testes curtos; sem definir um número específico, faço medições contínuas até interromper o processo. Para verificações recorrentes, guardo comandos em scripts e documento os Linha de base de um sistema. Esta rotina poupa tempo caso os problemas de carga voltem a ocorrer.

Comparação com a Top, a PS e outras marcas.

Para uma visão geral rápida, utilizo topo ou ps, mas, no que diz respeito à evolução e ao nível de detalhe, recorro ao pidstat. Os valores por intervalo permitem-me identificar as causas ao longo do tempo, em vez de me limitar a observar apenas os sintomas. Se precisar de uma visão mais aprofundada dos estrangulamentos da CPU, complemento a análise com Linux perf para amostras das pilhas de chamadas. É assim que combino as estatísticas do processo com a análise de desempenho, quando os valores de carga de trabalho por si só não são suficientes. Esta combinação proporciona-me indicações rápidas e uma análise fundamentada Diagnóstico.

Dicas práticas para o dia a dia

Tenho à minha disposição comandos que já deram provas e vou adaptando-os consoante a situação para Sistemas de produção. Carga da CPU em tempo real: pidstat -u 1. Memória em destaque: pidstat -r -p 2. Verificar se existe um estrangulamento de E/S: pidstat -d 1. Tópicos em destaque: pidstat -t -p 1. Para uma instrumentação mais aprofundada do sistema, recorro adicionalmente a Dicas sobre o bpftrace recorrer a ele quando os eventos do kernel precisarem do Spotlight.

Interpretar corretamente os resultados: eixos temporais e sistemas multicore

Presto atenção à forma como o pidstat define as referências temporais: O primeiro bloco de medição Por predefinição, apresenta valores médios desde o início do processo (ou desde o arranque do sistema); todos os blocos seguintes referem-se ao Intervalo. Para análises mais detalhadas, ignoro frequentemente o primeiro bloco e considero apenas os valores dos intervalos comparáveis em termos temporais.

Em Sistemas multicore Interpreto sempre o %CPU no contexto dos núcleos disponíveis. Um único processo pode, teoricamente, atingir até 800% num host de 8 núcleos, se escalar através de várias threads. Valores elevados de %system levam-me a pensar em chamadas de sistema, contenção de bloqueios ou filas de espera de E/S; valores elevados de %usr indicam rotinas computacionalmente intensivas no espaço do utilizador. O carimbo de data/hora antes de cada linha torna os valores atípicos claramente reconhecíveis ao longo do histórico e facilita a correlação com registos ou métricas de outras fontes.

Metodologia: formular hipóteses, selecionar janelas de medição

Nunca começo às cegas, mas sim formulei uma Hipótese Quanto à causa: „CPU-bound no espaço do utilizador“, „fila de E/S congestionada“, „memória a aumentar constantemente“. A partir daí, defino o intervalo de medição: no caso de picos curtos, utilizo intervalos de 1 a 2 segundos; no caso de Esquiadores de fundo mais bem 10 a 60 segundos. O importante é ajustar a janela à Dinâmica do sistema, de modo a não perder detalhes nem captar ruído desnecessário.

Além disso, faço medições antes e depois Alterações (por exemplo, lançamento, ajuste de configuração), para tornar visíveis os efeitos nas métricas. Uma análise clara Linha de base por ambiente (DEV, STAGE, PROD) ajuda-me a distinguir desvios reais dos padrões normais.

Registo permanente e acompanhamento

No caso de problemas difíceis de compreender, tomo notas durante um período de tempo definido e faço a análise posteriormente. Exemplo: pidstat -udwt 2 900 > /var/log/pidstat_$(date +%F_%H%M).log recolhe dados sobre a CPU, E/S, mudanças de contexto e threads durante 30 minutos, a cada 2 segundos. Posso visualizar a saída de texto estruturada com grep, awk ou um pequeno guião pós-processos, marcar picos e extrair PIDs que se destaquem. Para observações recorrentes, pretendo fazer um Esquema de rotação e selecione apenas os intervalos de tempo relevantes, para poupar espaço.

Quando preciso de vários ângulos de visão, combino os interruptores numa única sequência, em vez de iniciar várias ferramentas em paralelo. Isso mantém os resultados das medições síncrono e facilita a análise.

Containers, espaços de nomes e PIDs

Em ambientes de contentores, aplica-se o seguinte: Os PIDs estão em espaços de nomes. Se fizer a medição no host, vejo os PIDs do host; se fizer a medição no contentor, vejo os PIDs do contentor. Para uma identificação inequívoca, prefiro, por isso, filtrar por nome de comando com -C em vez de utilizar um único PID, que muda após um reinício. Se estiver a trabalhar no lado do host, complemento o contexto do processo (por exemplo, através do nome do serviço ou do pod nos registos), para poder associar posteriormente os valores medidos de forma clara a um Carga de trabalho atribuir. No caso de registos de longa duração, evito a armadilha do PID (Reutilização de PID) também através de filtros de nomes ou de registos complementares que documentam a duração do PID.

Medição segura em produção: custos indiretos, direitos, proteção de dados

Despesas gerais: o pidstat lê principalmente a partir de /proc e implica um esforço de medição mínimo. Em caso de intervalos muito curtos em hosts com elevada carga, aumentei ligeiramente o intervalo (por exemplo, de 1 para 2 segundos), para reduzir ainda mais o impacto na CPU. Faço medições seletivas (filtros!) em vez de „tudo, em todo o lado“.

Direitos e Segurança: Dependendo da configuração do sistema (hidepid em /proc) os detalhes não são visíveis para todos os utilizadores. No ambiente de produção, trabalho com direitos alargados quando necessário, mantenho a duração da medição curta e verifico se a exibição completa Linhas de comando poderia revelar parâmetros sensíveis. Os registos com dados de diagnóstico só devem ser guardados em locais onde sejam armazenados e eliminados de forma segura.

Reconhecer rapidamente padrões típicos

• Sistema 1TP1 elevado com %usr moderado: Indicação de pontos críticos próximos do kernel (utilização intensiva de chamadas de sistema, contenção de bloqueios, percursos dos controladores de rede/armazenamento). Estou a correlacionar estes dados com os valores de E/S e as mudanças de contexto.
• Muitas mudanças de contexto forçadas (cswch/s): Forte concorrência pelo tempo de CPU, frequentemente devido a recursos de CPU insuficientes ou a um número excessivo de threads ativos. Reduzir a carga, ajustar os tamanhos dos pools ou Afinidades verificar.
• Muitas mudanças de contexto voluntárias (vswch/s): Sincronização acentuada ou rendimentoFilas de espera baseadas em [...]. Estou a analisar os bloqueios, as estratégias de recuo e o comportamento do conjunto de threads.
• Aumento constante da capacidade de armazenamento: Suspeita de fuga. Vou verificar se Falhas de página (em especial majflt) e se o processo liberta memória após os picos de carga. Se não o fizer, comprovo isso através de uma medição com intervalos mais longos.
• Elevadas taxas de transferência de E/S com baixo débito no sistema: Em conjunto com os tempos de espera, os valores de E/S do processo indicam pontos de estrangulamento na pilha de armazenamento subjacente. Dou prioridade a medidas de otimização de E/S (agrupamento, armazenamento em cache, E/S assíncrona).
• Alguns tópicos destacam-seCom -t identifico o „Hot Thread“ e ajusto o conjunto de threads ou analiso especificamente o seu percurso de código.

Fluxos de trabalho na prática

Identificar o que está limitado pela CPU: Primeiro pidstat -u 1 globalmente, e depois de forma específica com -p ou -C. Se subir %usr, procuro o tópico em destaque com -t e, em seguida, analiso os resultados, se necessário, através do Sampling Profiler. Se predominarem os sistemas %s, analiso também as E/S e as mudanças de contexto.

Confirmar a existência de uma fuga de memória: Durante vários minutos com pidstat -r -p 5 observar. Estou a registar um aumento constante, sem qualquer diminuição após fases de carga. Paralelamente, verifico se as taxas de falhas de página ou os padrões de E/S explicam esse comportamento. Se a tendência se mantiver sem uma justificação válida, isso é um claro Indicador de fugas.

Detetar um engarrafamento de E/SCom pidstat -d 1 Identifico pontos críticos de leitura/gravação. Se observar uma carga significativa de gravação causada por poucos processos, concentro-me nos seus percursos de flush/sincronização e nos tamanhos dos lotes. A correlação com as mudanças de contexto ajuda-me a perceber se a CPU fica simultaneamente sob pressão.

Corrigir o desequilíbrio da rosca: pidstat -t -p 1 Mostra-me a carga e as mudanças de contexto por cada thread. Se um worker ficar significativamente mais sobrecarregado do que os restantes, ajusto o tamanho dos pools, a distribuição de tarefas ou Afinidade e verifica se a distribuição se normaliza nos próximos intervalos.

Limitações do pidstat e complementações úteis

O `pidstat` mostra o que consumiu recursos e quando acontece – isso não explica automaticamente o por que no caminho do código. Para perceber o „porquê“, recorro também ao Sampling Profiler ou a pontos de rastreio do kernel. No que diz respeito a questões relacionadas com a memória, o pidstat destaca tendências, mas não os ciclos de vida dos objetos. Por isso, considero o pidstat como Equipa de primeira intervenção, que me permite identificar as áreas problemáticas com o mínimo de esforço. Nos casos em que os valores de utilização por si só já não são suficientes, aprofundo a análise de forma específica com as ferramentas já mencionadas.

Lista de verificação para o arranque rápido

• Aprofundar a questão: CPU, RAM, E/S, threads ou mudança de contexto?
• Selecionar intervalo: Segundos para picos, minutos para tendências.
• Definir filtros: -p ou -C utilizar para manter a saída concisa.
• Primeiro, uma visão geral; depois, o foco: Iniciar de forma global, filtrar os processos que se destacam.
• Organizar o primeiro bloco: A primeira linha é calculada como média desde o início; depois, comparam-se os valores dos intervalos.
• Limitar a duração da medição: Recolher dados suficientes para identificar tendências, mas mantendo os registos sob controlo.
• Documentar: Registar a linha de base, a hipótese, os parâmetros de medição e as observações – é isso que torna as análises reproduzíveis.

Brevemente resumido

Com pidstat Recebo dados de processo baseados no tempo relativos à CPU, RAM, E/S, threads e mudanças de contexto, o que me permite identificar as verdadeiras causas dos padrões de carga. A combinação de filtros, intervalos e indicadores claros torna as análises direcionadas e reproduzíveis. Identifico tendências, em vez de me deixar enganar por instantâneos, e aplico as contramedidas adequadas. Comandos como pidstat -u 1, -r, -d e -w cobrem os casos mais comuns. Desta forma, garanto que os sistemas sejam transparentes, as decisões rápidas e os diagnósticos compreensível.