Saltar para o conteúdo 
Linux PSI fornece-me indicadores que mostram durante quanto tempo as tarefas ficam à espera da CPU, da memória ou da E/S, tornando assim visíveis os verdadeiros pontos de estrangulamento. Assim, consigo identificar com precisão quando os sistemas ficam bloqueados, em vez de me limitar a medir a carga de trabalho, e deduzir, a partir dos valores de pressão, medidas diretas para a análise de desempenho e a monitorização.
Pontos centrais
- parcial/total: Sinal de alerta precoce vs. bloqueio crítico
- CPU/memória/E/S: Custos por recurso claramente separados
- avg10/60/300: Intervalo de tempo para a avaliação de tendências
- Grupos C: Identificar os responsáveis e os afetados
- Gatilho: Reagir automaticamente quando o limite for ultrapassado
O que o Linux PSI mede e por que é importante
Vou ler um trecho de Pressão-As métricas indicam quanto tempo de trabalho efetivo os processos perdem devido à falta de tempo de CPU, RAM ou E/S. Os valores clássicos de utilização mostram apenas o grau de utilização dos recursos, enquanto o PSI revela com que frequência o sistema fica efetivamente parado. É precisamente isso que torna visível a distinção entre uma fila curta e um bloqueio total. Em configurações dinâmicas com contentores e implementações densas, consigo assim detetar estrangulamentos mais cedo e atribuí-los inequivocamente a um recurso. Desta forma, priorizo medidas de otimização de forma direcionada e evito ter de adivinhar qual é a verdadeira Causa.
Ativar e verificar o PSI no Linux
Primeiro, verifico se o PSI está ativo, consultando os ficheiros em /proc/pressure Leio; se a CPU, a memória e a E/S fornecerem valores, está tudo pronto. Se faltar algum dado, ativo o PSI com o parâmetro de arranque do kernel psi=1 ou certifico-me de que CONFIG_PSI=y está definido no kernel. Esta funcionalidade está disponível a partir do kernel 4.20 e, muitas vezes, já vem ativada nas distribuições atuais. Para verificações rápidas, bastam comandos simples como `cat /proc/pressure/cpu`, que me fornecem os valores avg10, avg60, avg300 e total. Assim, em poucos segundos, sei se o meu sistema apresenta Métricas fornece.
Compreender os ficheiros em /proc/pressure
Em /proc/pressure encontram-se três ficheiros para CPU, memory e io, que apresentam, cada um, dois tipos de saída: some e full. O some indica que pelo menos uma tarefa teve de ficar em espera, enquanto o full mostra que todas as tarefas não inativas estão bloqueadas simultaneamente. Além disso, obtenho médias móveis de 10, 60 e 300 segundos, bem como um valor total acumulado. Com base nestes intervalos de tempo, consigo distinguir picos de curta duração de problemas persistentes. Assim, avalio de forma objetiva se se tratam apenas de picos isolados ou se existe um problema persistente Pressão está disponível.
«some» vs. «full» na prática
Considero o «some» um indicador precoce e o «full» um sinal de alarme grave, pois o «full» descreve fases em que o trabalho produtivo fica, de facto, paralisado. Se o «some» aumentar na CPU, verifico o agendamento, os bloqueios e a distribuição de carga; neste caso, pode ser útil otimizar os threads ou medir o Medir a latência do agendador. Valores elevados de «memory-some» indicam frequentemente recuperação de páginas, troca de memória ou alocações dispendiosas. Se o «io-some» aumentar, analiso as filas de espera, as prioridades e os acessos concorrentes. Não tomo decisões com base na intuição, mas sim com base em critérios claros Sinais.
Análise a nível do sistema vs. análise baseada em cgroups
Começo por analisar a nível do sistema Valores, para obter uma visão geral, e depois mudo para os Cgroups para identificar as fontes. Com o cgroup v2, encontro ficheiros «pressure» específicos para cada serviço ou contentor, o que me permite associá-los a pods, slices ou unidades. Este procedimento separa os sintomas das fontes, em vez de atribuir todas as cargas de forma generalizada ao anfitrião. Em seguida, ajusto de forma específica as quotas, as quotas de CPU ou os limites de memória. Desta forma, aumento a equidade e reduzo a interferência mútua Influência.
PSI em monitorização, painéis de controlo e Kubernetes
Raramente recolho dados PSI manualmente; em vez disso, deixo que o Exporter exporte os dados como séries temporais registar, para que os painéis de controlo mostrem tendências e correlações. No Kubernetes, leio o PSI ao nível do nó, do pod e do contentor, o que permite uma separação clara entre o consumo e os estrangulamentos por cada carga de trabalho. Assim, consigo identificar se um único pod está a aumentar os tempos de espera para outros ou se o problema ocorre a nível do nó. Defino alertas para picos de desenvolvimento e para valores «some» persistentemente elevados. Desta forma, reajo de forma proativa, antes que os utilizadores enfrentem tempos de espera sentir.
Cenários de utilização típicos e limiares adequados
Utilizo o PSI em testes de carga para verificar se os tempos de resposta aumentam devido a pressão na CPU, na memória ou nas E/S e se isso ocorre apenas de forma temporária ou permanente. No planeamento de capacidade, acompanho o avg300 para identificar padrões recorrentes e, atempadamente, ampliar recursos ou redistribuir cargas de trabalho. Para o autoscaling, utilizo gatilhos próximos do limiar em que ocorre o estado «full», para poder reagir atempadamente. Em caso de deterioração gradual do desempenho, comparo as linhas de base antes e depois dos lançamentos, para tornar os efeitos transparentes. Assim, tomo decisões com base em factos e invisto onde há maior Efeito ...surge.
Verificação rápida em tabela das métricas PSI
Quando analiso o PSI, recorro a uma classificação simples para chegar mais rapidamente à hipótese correta. A tabela seguinte resume a interpretação de «some» e «full» por recurso e apresenta as primeiras opções de ação. Não substitui uma análise mais aprofundada, mas poupa-me tempo precioso durante o funcionamento. O essencial continua a ser avaliar os picos de curta duração de forma diferente das fases mais prolongadas. É precisamente para isso que utilizo os valores médios móveis avg10, avg60 e avg300 como Contexto.
| Recursos | some-Signal | Sinal «full» | Causas frequentes | Medidas possíveis |
|---|---|---|---|---|
| CPU | Períodos de espera ocasionais | Todas as tarefas bloqueadas | Conflitos de agendador, bloqueios, excesso de threads | Ajustar os conjuntos de threads, aliviar os bloqueios, ajustar as quotas/partilhas de CPU |
| Memória | Recuperações, falhas de página, congestionamento na alocação | Forte pressão, o swap domina | Excesso de alocação, heaps grandes, pressão na cache | Verificar limites, otimizar alocações, reduzir o swapping |
| E/S | Filas cada vez maiores | I/O é um conceito transversal | Discos/rede sobrecarregados, acessos concorrentes | Prioridades, agrupamento de tarefas, otimização da fila, volumes separados |
Interpretar corretamente a pressão no acumulador
Analiso o `memory.pressure` em conjunto com o RSS, as percentagens de cache e a utilização da área de troca, porque só esta combinação permite obter conclusões sólidas. Muitas vezes, por trás de um valor elevado de `some` está uma fase de libertações intensas ou um aumento de `page-faults`, que pode ser atenuado com melhores padrões de alocação. Se o valor «full» se tornar visível, interrompo as experiências e, em primeiro lugar, reduzo a pressão através de limites ou de caches menos agressivas. Uma introdução mais aprofundada ao tema é-me proporcionada por Pressão de memória com dicas práticas sobre o otimização da RAM. É assim que evito que o swapping descontrolado aumente os tempos de resposta dominado.
Detetar e resolver estrangulamentos de E/S
Analiso o io.pressure juntamente com as latências, as taxas de re-queue e as profundidades da fila, porque os valores puros de débito podem ocultar pontos de estrangulamento. Um valor elevado de some com uma carga de trabalho moderada indica-me frequentemente perfis de acesso irregulares, que podem ser suavizados através do processamento em lotes ou da priorização. Em caso de atrasos no primeiro byte e de um valor de «full» crescente, opto pela desconexão através de E/S assíncrona e por volumes separados para os hotpaths. Para diagnósticos detalhados, utilizo séries de medições e o guia comprovado no dia-a-dia sobre Analisar a espera de E/S. Assim, tomo decisões bem orientadas em vez de Pressupostos.
PSI vs. média de carga e métricas clássicas
Coloco deliberadamente o PSI ao lado da média de carga, da utilização da CPU, do iowait e da utilização da memória, para colmatar as lacunas entre estas perspetivas. Uma carga elevada com um cpu.pressure baixo indica-me, muitas vezes, apenas que muitas tarefas estão a ser processadas ativamente – sem engarrafamentos a nível do sistema. Por outro lado, um aumento da pressão da CPU (cpu.pressure) com uma utilização moderada é um indício de conflitos no agendador ou de contenção de bloqueios. No que diz respeito à E/S, o seguinte aplica-se: o iowait, por si só, não me diz até que ponto o sistema global é afetado; o io.pressure quantifica quanto tempo de trabalho se perde nesse processo. É precisamente esta tradução de “utilização” em “tempo perdido” que torna as minhas decisões significativamente mais fiáveis.
Janela do AVG e leitura totalmente precisa
Considero os valores avg10/60/300 como percentagens do tempo durante o qual as tarefas estiveram bloqueadas. Um valor avg10 de 2,50 significa que, nos últimos 10 segundos, perderam-se 2,51 TP3T do tempo de trabalho potencial. O valor «total» acumula o tempo de bloqueio desde o arranque (em unidades de tempo de alta precisão) e mostra-me, assim, o Área sob a curva. Para o planeamento da capacidade, analiso a inclinação dos perfis diários em relação ao total: se a linha se tornar significativamente mais íngreme nas fases de pico, planeio medidas para aliviar a carga. No que diz respeito aos sinais operacionais, analiso os padrões: um breve aumento no «avg10» preocupa-me menos do que um aumento paralelo do «avg60» e do «avg300», o que indica pressão estrutural.
Cgroups na prática: estrutura, caminhos e permissões
Trabalho com o cgroup v2 utilizando os ficheiros «pressure» diretamente nos respetivos diretórios de serviço, slice ou pod. Desta forma, consigo identificar, por unidade, pod ou contentor, se a pressão é gerada localmente ou se é apenas reenviada. Desta forma, é possível distinguir claramente as unidades do systemd, os pods do Kubernetes e os grupos definidos pelo utilizador. Se a atribuição for bem-sucedida, aplico restrições de forma específica: quotas de CPU mais restritas, partilhas de CPU mais justas e limites de memória realistas. Na prática, tenho o cuidado de efetuar a medição exatamente onde ela tem efeito – no Cgroup que define os limites. Isto evita que eu combata os sintomas num ponto, enquanto a verdadeira fonte permanece inalterada.
Estratégias de alerta sem uma enxurrada de alertas
Defino os alarmes de forma a terem em conta as tendências e a persistência. Para a deteção precoce, defino os valores-limite em «some», combino-os com janelas de observação e histerese e verifico se avg10 e O avg60 deve permanecer elevado. Para intervenções urgentes, associo o valor total a janelas curtas e reações automáticas (escalonamento, priorização, limitação). Para evitar oscilações, só ativo a ação quando um estado é confirmado várias vezes e só volto atrás quando os valores caem significativamente abaixo do limiar de retorno. Associo os alertas aos SLOs dos serviços: se as latências p95 aumentarem e, ao mesmo tempo, a carga aumentar, o resultado é fiável – a carga de trabalho por si só não me basta para isso.
Exemplos práticos: padrões que reconheço imediatamente
Gosto de recolher padrões recorrentes, porque aceleram a tomada de decisões:
- CPU: Conflito de bloqueio em vez de “número insuficiente de núcleos” – O valor de `cpu.some` aumenta, apesar de a utilização da CPU não estar no limite. Estou a analisar os hotlocks, a reduzir a dispersão de threads e a suavizar os picos com contrapressão. Muitas vezes, isto traz melhores resultados do que a adição de núcleos adicionais.
- Memória: Espiral de Recuperação – O «memory.some» aumenta e oscila com erros de página, enquanto o swap é ativado. Diminuo a agressividade da cache, reduzo os picos do heap (por exemplo, tamanhos de lote), ajusto os limites e, assim, evito que o «memory.full» seja sequer visível.
- E/S: Acessos desequilibrados – O io.some aumenta, embora a taxa de transferência se mantenha normal. Desacoplo as vias de leitura e escrita, agrupo pequenas operações de E/S em lotes e distribuo as vias de acesso mais intensas por volumes próprios. Desta forma, reduzo os tempos de espera sem aumentar necessariamente a taxa de transferência pura.
Limites e obstáculos na interpretação
Tenho em conta que o PSI mede o tempo de espera – e não a carga de trabalho absoluta. Um trabalho em lote limitado pela CPU pode apresentar uma carga elevada sem aumentar o cpu.pressure, desde que haja núcleos suficientes disponíveis. Por outro lado, um baixo débito acompanhado de um io.pressure elevado pode indicar um claro congestionamento. Em ambientes virtualizados, verifico também se os limites ou as afinidades estão a criar estrangulamentos locais: um contentor que esteja restrito a apenas alguns núcleos pode apresentar um cpu.pressure elevado, apesar de o anfitrião ter recursos disponíveis. É igualmente importante comparar a perspetiva a nível do sistema com a perspetiva local do cgroup – só assim consigo perceber se estou a resolver o problema no local certo.
Parâmetros operacionais: amostragem, custos indiretos e visualização
Mantenho a amostragem simples: um intervalo de 1 a 5 segundos é suficiente para as minhas decisões operacionais, porque as janelas médias já suavizam os dados. Considero a sobrecarga do PSI insignificante, sobretudo porque mantenho a medição próxima do sistema e registo apenas algumas séries temporais bem posicionadas. Para a visualização, coloco painéis lado a lado por cada recurso (some/full, avg10/60/300, total) e correlaciono-os com as taxas de latência e de erros. Nas análises pós-incidente, traço a inclinação do valor «total» em função das implementações, lançamentos ou alterações de configuração — assim fica claro quais as medidas que realmente reduzem a pressão.
Medidas específicas por recurso
A partir dos padrões, deduzo medidas concretas, sem recorrer automaticamente a hardware adicional:
- CPU: Limitar os conjuntos de threads e os mecanismos de controlo de concorrência, mitigar os hotlocks (granularidade/estratégia de bloqueio), distribuir a carga de forma equitativa (quotas/partilhas), ter em conta a topologia (NUMA, afinidade). Só quando a redução da carga a nível local não for eficaz é que procedo à escalabilidade horizontal ou vertical.
- Memória: Estabilizar as alocações (agrupamento, buffer), controlar as caches, definir limites realistas, atenuar os picos do heap, reduzir o impacto do swap. Faço medições específicas antes e depois das alterações, pois o memory.some é sensível aos padrões de alocação.
- E/S: Suavizar os perfis de acesso (processamento em lote, E/S assíncrona), desacoplar os hotpaths, definir prioridades, selecionar profundidades de fila adequadas e separar cargas de trabalho concorrentes. Avalio o sucesso com base na diminuição da pressão de E/S e em latências P99 mais curtas.
O PSI no dia-a-dia da equipa: comunicação e sentido de responsabilidade
Também utilizo o PSI como linguagem comum entre as equipas da plataforma e as equipas de produto. Em vez de falar de forma abstrata sobre “lentidão”, identifico o recurso e o padrão: “io.some avg60 há 20 minutos acima de 4% no Serviço X” ou “memory.full é acionado no cgroup Y”. Esta precisão facilita a definição de prioridades, porque fica claro quais os responsáveis que têm de agir e qual o orçamento (tempo, recursos) que promete os maiores resultados. Através de valores de referência definidos, estabeleço objetivos de qualidade que são tecnicamente sólidos e, ao mesmo tempo, compreensíveis para as partes interessadas.
Desencadeadores, linhas de base e implementação gradual
Utilizo os PSI-Trigger com valores-limite e janelas de observação para que um daemon reaja automaticamente quando a pressão se mantém elevada. Para obter conclusões fiáveis, antes de efetuar alterações, crio uma linha de base com base em fases de carga típicas, que posteriormente comparo com novas séries de medições. Defino os alertas de forma conservadora: o estado «some» (elevado de forma prolongada) dá-me tempo, enquanto o estado «full» (máximo) desencadeia contramedidas. Em grandes frotas, implemento os alertas baseados no PSI por fases, para evitar ruído e ajustar as tolerâncias com precisão. Assim, o meu monitorização claro e resistente, sem sobrecarregar as equipas com notificações desnecessárias.
Vantagens para alojamento, virtualização e multi-tenant
Com o PSI, verifico se determinadas cargas de trabalho estão a atrasar outras, se as reservas de hardware são suficientes e onde é necessário ajustar os limites. Em ambientes partilhados, identifico a pressão contínua sobre a CPU, a memória ou as E/S gerada por contas individuais e planeio as realocações atempadamente. Os valores baseados em cgroups mostram-me quais os serviços afetados e onde devo limitar ou priorizar de forma específica. Desta forma, mantenho tempos de resposta fiáveis e garanto uma utilização justa dos recursos, mesmo sob carga. Isto reduz os custos, evita escaladas e aumenta a qualidade.
Conclusão: os indicadores transformam-se em decisões
Utilizo o Linux PSI porque torna os tempos de espera mensuráveis e, assim, colmata a lacuna entre a carga do sistema e a experiência do utilizador. Com o «some» deteto sinais precoces, com o «full» reajo a bloqueios reais e, com os Cgroups, identifico as causas exatas. Os painéis, os gatilhos e as linhas de base transformam esta visão em medidas concretas: limites otimizados, melhor distribuição de carga, percursos de E/S limpos. Quem utiliza ativamente o PSI reduz o tempo necessário para identificar a causa e evita muitas iterações de afinação às cegas. Assim, os dados de monitorização transformam-se em Decisões, que tornam os sistemas visivelmente mais rápidos.
