{"id":21247,"date":"2026-09-01T18:19:15","date_gmt":"2026-09-01T16:19:15","guid":{"rendered":"https:\/\/webhosting.de\/linux-psi-pressure-stall-information-performanceanalyse-serverdruck\/"},"modified":"2026-09-01T18:19:15","modified_gmt":"2026-09-01T16:19:15","slug":"linux-psi-pressao-bloqueio-informacao-analise-de-desempenho-pressao-do-servidor","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/linux-psi-pressure-stall-information-performanceanalyse-serverdruck\/","title":{"rendered":"Linux PSI para uma an\u00e1lise e monitoriza\u00e7\u00e3o precisas do desempenho"},"content":{"rendered":"<p><strong>Linux PSI<\/strong> fornece-me indicadores que mostram durante quanto tempo as tarefas ficam \u00e0 espera da CPU, da mem\u00f3ria ou da E\/S, tornando assim vis\u00edveis os verdadeiros pontos de estrangulamento. Assim, consigo identificar com precis\u00e3o quando os sistemas ficam bloqueados, em vez de me limitar a medir a carga de trabalho, e deduzir, a partir dos valores de press\u00e3o, medidas diretas para a an\u00e1lise de desempenho e a monitoriza\u00e7\u00e3o.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<ul>\n  <li><strong>parcial\/total<\/strong>: Sinal de alerta precoce vs. bloqueio cr\u00edtico<\/li>\n  <li><strong>CPU\/mem\u00f3ria\/E\/S<\/strong>: Custos por recurso claramente separados<\/li>\n  <li><strong>avg10\/60\/300<\/strong>: Intervalo de tempo para a avalia\u00e7\u00e3o de tend\u00eancias<\/li>\n  <li><strong>Grupos C<\/strong>: Identificar os respons\u00e1veis e os afetados<\/li>\n  <li><strong>Gatilho<\/strong>: Reagir automaticamente quando o limite for ultrapassado<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-performance-monitoring-4826.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>O que o Linux PSI mede e por que \u00e9 importante<\/h2>\n<p>Vou ler um trecho de <strong>Press\u00e3o<\/strong>-As m\u00e9tricas indicam quanto tempo de trabalho efetivo os processos perdem devido \u00e0 falta de tempo de CPU, RAM ou E\/S. Os valores cl\u00e1ssicos de utiliza\u00e7\u00e3o mostram apenas o grau de utiliza\u00e7\u00e3o dos recursos, enquanto o PSI revela com que frequ\u00eancia o sistema fica efetivamente parado. \u00c9 precisamente isso que torna vis\u00edvel a distin\u00e7\u00e3o entre uma fila curta e um bloqueio total. Em configura\u00e7\u00f5es din\u00e2micas com contentores e implementa\u00e7\u00f5es densas, consigo assim detetar estrangulamentos mais cedo e atribu\u00ed-los inequivocamente a um recurso. Desta forma, priorizo medidas de otimiza\u00e7\u00e3o de forma direcionada e evito ter de adivinhar qual \u00e9 a verdadeira <strong>Causa<\/strong>.<\/p>\n\n<h2>Ativar e verificar o PSI no Linux<\/h2>\n<p>Primeiro, verifico se o PSI est\u00e1 ativo, consultando os ficheiros em <strong>\/proc\/pressure<\/strong> Leio; se a CPU, a mem\u00f3ria e a E\/S fornecerem valores, est\u00e1 tudo pronto. Se faltar algum dado, ativo o PSI com o par\u00e2metro de arranque do kernel psi=1 ou certifico-me de que CONFIG_PSI=y est\u00e1 definido no kernel. Esta funcionalidade est\u00e1 dispon\u00edvel a partir do kernel 4.20 e, muitas vezes, j\u00e1 vem ativada nas distribui\u00e7\u00f5es atuais. Para verifica\u00e7\u00f5es r\u00e1pidas, 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 <strong>M\u00e9tricas<\/strong> fornece.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-performancemeeting-7283.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Compreender os ficheiros em \/proc\/pressure<\/h2>\n<p>Em \/proc\/pressure encontram-se tr\u00eas ficheiros para <strong>CPU<\/strong>, memory e io, que apresentam, cada um, dois tipos de sa\u00edda: 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\u00e3o inativas est\u00e3o bloqueadas simultaneamente. Al\u00e9m disso, obtenho m\u00e9dias m\u00f3veis de 10, 60 e 300 segundos, bem como um valor total acumulado. Com base nestes intervalos de tempo, consigo distinguir picos de curta dura\u00e7\u00e3o de problemas persistentes. Assim, avalio de forma objetiva se se tratam apenas de picos isolados ou se existe um problema persistente <strong>Press\u00e3o<\/strong> est\u00e1 dispon\u00edvel.<\/p>\n\n<h2>\u00absome\u00bb vs. \u00abfull\u00bb na pr\u00e1tica<\/h2>\n<p>Considero o \u00absome\u00bb um indicador precoce e o \u00abfull\u00bb um sinal de alarme grave, pois o \u00abfull\u00bb descreve fases em que o trabalho produtivo fica, de facto, paralisado. Se o \u00absome\u00bb aumentar na CPU, verifico o agendamento, os bloqueios e a distribui\u00e7\u00e3o de carga; neste caso, pode ser \u00fatil otimizar os threads ou medir o <a href=\"https:\/\/webhosting.de\/pt\/medir-a-latencia-do-agendador-do-linux-e-otimizar-o-desempenho\/\">Medir a lat\u00eancia do agendador<\/a>. Valores elevados de \u00abmemory-some\u00bb indicam frequentemente recupera\u00e7\u00e3o de p\u00e1ginas, troca de mem\u00f3ria ou aloca\u00e7\u00f5es dispendiosas. Se o \u00abio-some\u00bb aumentar, analiso as filas de espera, as prioridades e os acessos concorrentes. N\u00e3o tomo decis\u00f5es com base na intui\u00e7\u00e3o, mas sim com base em crit\u00e9rios claros <strong>Sinais<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-psi-performance-analysis-4723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>An\u00e1lise a n\u00edvel do sistema vs. an\u00e1lise baseada em cgroups<\/h2>\n<p>Come\u00e7o por analisar a n\u00edvel do sistema <strong>Valores<\/strong>, para obter uma vis\u00e3o geral, e depois mudo para os Cgroups para identificar as fontes. Com o cgroup v2, encontro ficheiros \u00abpressure\u00bb espec\u00edficos para cada servi\u00e7o ou contentor, o que me permite associ\u00e1-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\u00e3o. Em seguida, ajusto de forma espec\u00edfica as quotas, as quotas de CPU ou os limites de mem\u00f3ria. Desta forma, aumento a equidade e reduzo a interfer\u00eancia m\u00fatua <strong>Influ\u00eancia<\/strong>.<\/p>\n\n<h2>PSI em monitoriza\u00e7\u00e3o, pain\u00e9is de controlo e Kubernetes<\/h2>\n<p>Raramente recolho dados PSI manualmente; em vez disso, deixo que o Exporter exporte os dados como <strong>s\u00e9ries temporais<\/strong> registar, para que os pain\u00e9is de controlo mostrem tend\u00eancias e correla\u00e7\u00f5es. No Kubernetes, leio o PSI ao n\u00edvel do n\u00f3, do pod e do contentor, o que permite uma separa\u00e7\u00e3o clara entre o consumo e os estrangulamentos por cada carga de trabalho. Assim, consigo identificar se um \u00fanico pod est\u00e1 a aumentar os tempos de espera para outros ou se o problema ocorre a n\u00edvel do n\u00f3. Defino alertas para picos de desenvolvimento e para valores \u00absome\u00bb persistentemente elevados. Desta forma, reajo de forma proativa, antes que os utilizadores enfrentem tempos de espera <strong>sentir<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux_performance_nacht_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cen\u00e1rios de utiliza\u00e7\u00e3o t\u00edpicos e limiares adequados<\/h2>\n<p>Utilizo o PSI em testes de carga para verificar se os tempos de resposta aumentam devido a press\u00e3o na CPU, na mem\u00f3ria ou nas E\/S e se isso ocorre apenas de forma tempor\u00e1ria ou permanente. No planeamento de capacidade, acompanho o avg300 para identificar padr\u00f5es recorrentes e, atempadamente, ampliar recursos ou redistribuir cargas de trabalho. Para o autoscaling, utilizo gatilhos pr\u00f3ximos do limiar em que ocorre o estado \u00abfull\u00bb, para poder reagir atempadamente. Em caso de deteriora\u00e7\u00e3o gradual do desempenho, comparo as linhas de base antes e depois dos lan\u00e7amentos, para tornar os efeitos transparentes. Assim, tomo decis\u00f5es com base em factos e invisto onde h\u00e1 maior <strong>Efeito<\/strong> ...surge.<\/p>\n\n<h2>Verifica\u00e7\u00e3o r\u00e1pida em tabela das m\u00e9tricas PSI<\/h2>\n<p>Quando analiso o PSI, recorro a uma classifica\u00e7\u00e3o simples para chegar mais rapidamente \u00e0 hip\u00f3tese correta. A tabela seguinte resume a interpreta\u00e7\u00e3o de \u00absome\u00bb e \u00abfull\u00bb por recurso e apresenta as primeiras op\u00e7\u00f5es de a\u00e7\u00e3o. N\u00e3o substitui uma an\u00e1lise mais aprofundada, mas poupa-me tempo precioso durante o funcionamento. O essencial continua a ser avaliar os picos de curta dura\u00e7\u00e3o de forma diferente das fases mais prolongadas. \u00c9 precisamente para isso que utilizo os valores m\u00e9dios m\u00f3veis avg10, avg60 e avg300 como <strong>Contexto<\/strong>.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Recursos<\/th>\n      <th>some-Signal<\/th>\n      <th>Sinal \u00abfull\u00bb<\/th>\n      <th>Causas frequentes<\/th>\n      <th>Medidas poss\u00edveis<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>CPU<\/td>\n      <td>Per\u00edodos de espera ocasionais<\/td>\n      <td>Todas as tarefas bloqueadas<\/td>\n      <td>Conflitos de agendador, bloqueios, excesso de threads<\/td>\n      <td>Ajustar os conjuntos de threads, aliviar os bloqueios, ajustar as quotas\/partilhas de CPU<\/td>\n    <\/tr>\n    <tr>\n      <td>Mem\u00f3ria<\/td>\n      <td>Recupera\u00e7\u00f5es, falhas de p\u00e1gina, congestionamento na aloca\u00e7\u00e3o<\/td>\n      <td>Forte press\u00e3o, o swap domina<\/td>\n      <td>Excesso de aloca\u00e7\u00e3o, heaps grandes, press\u00e3o na cache<\/td>\n      <td>Verificar limites, otimizar aloca\u00e7\u00f5es, reduzir o swapping<\/td>\n    <\/tr>\n    <tr>\n      <td>E\/S<\/td>\n      <td>Filas cada vez maiores<\/td>\n      <td>I\/O \u00e9 um conceito transversal<\/td>\n      <td>Discos\/rede sobrecarregados, acessos concorrentes<\/td>\n      <td>Prioridades, agrupamento de tarefas, otimiza\u00e7\u00e3o da fila, volumes separados<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Interpretar corretamente a press\u00e3o no acumulador<\/h2>\n<p>Analiso o `memory.pressure` em conjunto com o RSS, as percentagens de cache e a utiliza\u00e7\u00e3o da \u00e1rea de troca, porque s\u00f3 esta combina\u00e7\u00e3o permite obter conclus\u00f5es s\u00f3lidas. Muitas vezes, por tr\u00e1s de um valor elevado de `some` est\u00e1 uma fase de liberta\u00e7\u00f5es intensas ou um aumento de `page-faults`, que pode ser atenuado com melhores padr\u00f5es de aloca\u00e7\u00e3o. Se o valor \u00abfull\u00bb se tornar vis\u00edvel, interrompo as experi\u00eancias e, em primeiro lugar, reduzo a press\u00e3o atrav\u00e9s de limites ou de caches menos agressivas. Uma introdu\u00e7\u00e3o mais aprofundada ao tema \u00e9-me proporcionada por <a href=\"https:\/\/webhosting.de\/pt\/pressao-de-memoria-kernel-do-linux-sistemas-de-alojamento-otimizacao-ram\/\">Press\u00e3o de mem\u00f3ria<\/a> com dicas pr\u00e1ticas sobre o otimiza\u00e7\u00e3o da RAM. \u00c9 assim que evito que o swapping descontrolado aumente os tempos de resposta <strong>dominado<\/strong>.<\/p>\n\n<h2>Detetar e resolver estrangulamentos de E\/S<\/h2>\n<p>Analiso o io.pressure juntamente com as lat\u00eancias, as taxas de re-queue e as profundidades da fila, porque os valores puros de d\u00e9bito 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\u00e9s do processamento em lotes ou da prioriza\u00e7\u00e3o. Em caso de atrasos no primeiro byte e de um valor de \u00abfull\u00bb crescente, opto pela desconex\u00e3o atrav\u00e9s de E\/S ass\u00edncrona e por volumes separados para os hotpaths. Para diagn\u00f3sticos detalhados, utilizo s\u00e9ries de medi\u00e7\u00f5es e o guia comprovado no dia-a-dia sobre <a href=\"https:\/\/webhosting.de\/pt\/server-io-wait-analyse-iostat-vmstat-metrics-disk\/\">Analisar a espera de E\/S<\/a>. Assim, tomo decis\u00f5es bem orientadas em vez de <strong>Pressupostos<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-performanceanalyse-1928.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>PSI vs. m\u00e9dia de carga e m\u00e9tricas cl\u00e1ssicas<\/h2>\n<p>Coloco deliberadamente o PSI ao lado da m\u00e9dia de carga, da utiliza\u00e7\u00e3o da CPU, do iowait e da utiliza\u00e7\u00e3o da mem\u00f3ria, para colmatar as lacunas entre estas perspetivas. Uma carga elevada com um cpu.pressure baixo indica-me, muitas vezes, apenas que muitas tarefas est\u00e3o a ser processadas ativamente \u2013 sem engarrafamentos a n\u00edvel do sistema. Por outro lado, um aumento da press\u00e3o da CPU (cpu.pressure) com uma utiliza\u00e7\u00e3o moderada \u00e9 um ind\u00edcio de conflitos no agendador ou de conten\u00e7\u00e3o de bloqueios. No que diz respeito \u00e0 E\/S, o seguinte aplica-se: o iowait, por si s\u00f3, n\u00e3o me diz at\u00e9 que ponto o sistema global \u00e9 afetado; o io.pressure quantifica quanto tempo de trabalho se perde nesse processo. \u00c9 precisamente esta tradu\u00e7\u00e3o de \u201cutiliza\u00e7\u00e3o\u201d em \u201ctempo perdido\u201d que torna as minhas decis\u00f5es significativamente mais fi\u00e1veis.<\/p>\n\n<h2>Janela do AVG e leitura totalmente precisa<\/h2>\n<p>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 \u00faltimos 10 segundos, perderam-se 2,51 TP3T do tempo de trabalho potencial. O valor \u00abtotal\u00bb acumula o tempo de bloqueio desde o arranque (em unidades de tempo de alta precis\u00e3o) e mostra-me, assim, o <strong>\u00c1rea sob a curva<\/strong>. Para o planeamento da capacidade, analiso a inclina\u00e7\u00e3o dos perfis di\u00e1rios em rela\u00e7\u00e3o ao total: se a linha se tornar significativamente mais \u00edngreme nas fases de pico, planeio medidas para aliviar a carga. No que diz respeito aos sinais operacionais, analiso os padr\u00f5es: um breve aumento no \u00abavg10\u00bb preocupa-me menos do que um aumento paralelo do \u00abavg60\u00bb e do \u00abavg300\u00bb, o que indica press\u00e3o estrutural.<\/p>\n\n<h2>Cgroups na pr\u00e1tica: estrutura, caminhos e permiss\u00f5es<\/h2>\n<p>Trabalho com o cgroup v2 utilizando os ficheiros \u00abpressure\u00bb diretamente nos respetivos diret\u00f3rios de servi\u00e7o, slice ou pod. Desta forma, consigo identificar, por unidade, pod ou contentor, se a press\u00e3o \u00e9 gerada localmente ou se \u00e9 apenas reenviada. Desta forma, \u00e9 poss\u00edvel distinguir claramente as unidades do systemd, os pods do Kubernetes e os grupos definidos pelo utilizador. Se a atribui\u00e7\u00e3o for bem-sucedida, aplico restri\u00e7\u00f5es de forma espec\u00edfica: quotas de CPU mais restritas, partilhas de CPU mais justas e limites de mem\u00f3ria realistas. Na pr\u00e1tica, tenho o cuidado de efetuar a medi\u00e7\u00e3o exatamente onde ela tem efeito \u2013 no Cgroup que define os limites. Isto evita que eu combata os sintomas num ponto, enquanto a verdadeira fonte permanece inalterada.<\/p>\n\n<h2>Estrat\u00e9gias de alerta sem uma enxurrada de alertas<\/h2>\n<p>Defino os alarmes de forma a terem em conta as tend\u00eancias e a persist\u00eancia. Para a dete\u00e7\u00e3o precoce, defino os valores-limite em \u00absome\u00bb, combino-os com janelas de observa\u00e7\u00e3o e histerese e verifico se avg10 <em>e<\/em> O avg60 deve permanecer elevado. Para interven\u00e7\u00f5es urgentes, associo o valor total a janelas curtas e rea\u00e7\u00f5es autom\u00e1ticas (escalonamento, prioriza\u00e7\u00e3o, limita\u00e7\u00e3o). Para evitar oscila\u00e7\u00f5es, s\u00f3 ativo a a\u00e7\u00e3o quando um estado \u00e9 confirmado v\u00e1rias vezes e s\u00f3 volto atr\u00e1s quando os valores caem significativamente abaixo do limiar de retorno. Associo os alertas aos SLOs dos servi\u00e7os: se as lat\u00eancias p95 aumentarem e, ao mesmo tempo, a carga aumentar, o resultado \u00e9 fi\u00e1vel \u2013 a carga de trabalho por si s\u00f3 n\u00e3o me basta para isso.<\/p>\n\n<h2>Exemplos pr\u00e1ticos: padr\u00f5es que reconhe\u00e7o imediatamente<\/h2>\n<p>Gosto de recolher padr\u00f5es recorrentes, porque aceleram a tomada de decis\u00f5es:<\/p>\n<ul>\n  <li><strong>CPU: Conflito de bloqueio em vez de \u201cn\u00famero insuficiente de n\u00facleos\u201d<\/strong> \u2013 O valor de `cpu.some` aumenta, apesar de a utiliza\u00e7\u00e3o da CPU n\u00e3o estar no limite. Estou a analisar os hotlocks, a reduzir a dispers\u00e3o de threads e a suavizar os picos com contrapress\u00e3o. Muitas vezes, isto traz melhores resultados do que a adi\u00e7\u00e3o de n\u00facleos adicionais.<\/li>\n  <li><strong>Mem\u00f3ria: Espiral de Recupera\u00e7\u00e3o<\/strong> \u2013 O \u00abmemory.some\u00bb aumenta e oscila com erros de p\u00e1gina, enquanto o swap \u00e9 ativado. Diminuo a agressividade da cache, reduzo os picos do heap (por exemplo, tamanhos de lote), ajusto os limites e, assim, evito que o \u00abmemory.full\u00bb seja sequer vis\u00edvel.<\/li>\n  <li><strong>E\/S: Acessos desequilibrados<\/strong> \u2013 O io.some aumenta, embora a taxa de transfer\u00eancia se mantenha normal. Desacoplo as vias de leitura e escrita, agrupo pequenas opera\u00e7\u00f5es de E\/S em lotes e distribuo as vias de acesso mais intensas por volumes pr\u00f3prios. Desta forma, reduzo os tempos de espera sem aumentar necessariamente a taxa de transfer\u00eancia pura.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/developer_desk_9502.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Limites e obst\u00e1culos na interpreta\u00e7\u00e3o<\/h2>\n<p>Tenho em conta que o PSI mede o tempo de espera \u2013 e n\u00e3o 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\u00facleos suficientes dispon\u00edveis. Por outro lado, um baixo d\u00e9bito acompanhado de um io.pressure elevado pode indicar um claro congestionamento. Em ambientes virtualizados, verifico tamb\u00e9m se os limites ou as afinidades est\u00e3o a criar estrangulamentos locais: um contentor que esteja restrito a apenas alguns n\u00facleos pode apresentar um cpu.pressure elevado, apesar de o anfitri\u00e3o ter recursos dispon\u00edveis. \u00c9 igualmente importante comparar a perspetiva a n\u00edvel do sistema com a perspetiva local do cgroup \u2013 s\u00f3 assim consigo perceber se estou a resolver o problema no local certo.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/linux-performanceanalyse-1928.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Par\u00e2metros operacionais: amostragem, custos indiretos e visualiza\u00e7\u00e3o<\/h2>\n<p>Mantenho a amostragem simples: um intervalo de 1 a 5 segundos \u00e9 suficiente para as minhas decis\u00f5es operacionais, porque as janelas m\u00e9dias j\u00e1 suavizam os dados. Considero a sobrecarga do PSI insignificante, sobretudo porque mantenho a medi\u00e7\u00e3o pr\u00f3xima do sistema e registo apenas algumas s\u00e9ries temporais bem posicionadas. Para a visualiza\u00e7\u00e3o, coloco pain\u00e9is lado a lado por cada recurso (some\/full, avg10\/60\/300, total) e correlaciono-os com as taxas de lat\u00eancia e de erros. Nas an\u00e1lises p\u00f3s-incidente, tra\u00e7o a inclina\u00e7\u00e3o do valor \u00abtotal\u00bb em fun\u00e7\u00e3o das implementa\u00e7\u00f5es, lan\u00e7amentos ou altera\u00e7\u00f5es de configura\u00e7\u00e3o \u2014 assim fica claro quais as medidas que realmente reduzem a press\u00e3o.<\/p>\n\n<h2>Medidas espec\u00edficas por recurso<\/h2>\n<p>A partir dos padr\u00f5es, deduzo medidas concretas, sem recorrer automaticamente a hardware adicional:<\/p>\n<ul>\n  <li><strong>CPU<\/strong>: Limitar os conjuntos de threads e os mecanismos de controlo de concorr\u00eancia, mitigar os hotlocks (granularidade\/estrat\u00e9gia de bloqueio), distribuir a carga de forma equitativa (quotas\/partilhas), ter em conta a topologia (NUMA, afinidade). S\u00f3 quando a redu\u00e7\u00e3o da carga a n\u00edvel local n\u00e3o for eficaz \u00e9 que procedo \u00e0 escalabilidade horizontal ou vertical.<\/li>\n  <li><strong>Mem\u00f3ria<\/strong>: Estabilizar as aloca\u00e7\u00f5es (agrupamento, buffer), controlar as caches, definir limites realistas, atenuar os picos do heap, reduzir o impacto do swap. Fa\u00e7o medi\u00e7\u00f5es espec\u00edficas antes e depois das altera\u00e7\u00f5es, pois o memory.some \u00e9 sens\u00edvel aos padr\u00f5es de aloca\u00e7\u00e3o.<\/li>\n  <li><strong>E\/S<\/strong>: Suavizar os perfis de acesso (processamento em lote, E\/S ass\u00edncrona), desacoplar os hotpaths, definir prioridades, selecionar profundidades de fila adequadas e separar cargas de trabalho concorrentes. Avalio o sucesso com base na diminui\u00e7\u00e3o da press\u00e3o de E\/S e em lat\u00eancias P99 mais curtas.<\/li>\n<\/ul>\n\n<h2>O PSI no dia-a-dia da equipa: comunica\u00e7\u00e3o e sentido de responsabilidade<\/h2>\n<p>Tamb\u00e9m utilizo o PSI como linguagem comum entre as equipas da plataforma e as equipas de produto. Em vez de falar de forma abstrata sobre \u201clentid\u00e3o\u201d, identifico o recurso e o padr\u00e3o: \u201cio.some avg60 h\u00e1 20 minutos acima de 4% no Servi\u00e7o X\u201d ou \u201cmemory.full \u00e9 acionado no cgroup Y\u201d. Esta precis\u00e3o facilita a defini\u00e7\u00e3o de prioridades, porque fica claro quais os respons\u00e1veis que t\u00eam de agir e qual o or\u00e7amento (tempo, recursos) que promete os maiores resultados. Atrav\u00e9s de valores de refer\u00eancia definidos, estabele\u00e7o objetivos de qualidade que s\u00e3o tecnicamente s\u00f3lidos e, ao mesmo tempo, compreens\u00edveis para as partes interessadas.<\/p>\n\n<h2>Desencadeadores, linhas de base e implementa\u00e7\u00e3o gradual<\/h2>\n<p>Utilizo os PSI-Trigger com valores-limite e janelas de observa\u00e7\u00e3o para que um daemon reaja automaticamente quando a press\u00e3o se mant\u00e9m elevada. Para obter conclus\u00f5es fi\u00e1veis, antes de efetuar altera\u00e7\u00f5es, crio uma linha de base com base em fases de carga t\u00edpicas, que posteriormente comparo com novas s\u00e9ries de medi\u00e7\u00f5es. Defino os alertas de forma conservadora: o estado \u00absome\u00bb (elevado de forma prolongada) d\u00e1-me tempo, enquanto o estado \u00abfull\u00bb (m\u00e1ximo) desencadeia contramedidas. Em grandes frotas, implemento os alertas baseados no PSI por fases, para evitar ru\u00eddo e ajustar as toler\u00e2ncias com precis\u00e3o. Assim, o meu monitoriza\u00e7\u00e3o <strong>claro<\/strong> e resistente, sem sobrecarregar as equipas com notifica\u00e7\u00f5es desnecess\u00e1rias.<\/p>\n\n<h2>Vantagens para alojamento, virtualiza\u00e7\u00e3o e multi-tenant<\/h2>\n<p>Com o PSI, verifico se determinadas cargas de trabalho est\u00e3o a atrasar outras, se as reservas de hardware s\u00e3o suficientes e onde \u00e9 necess\u00e1rio ajustar os limites. Em ambientes partilhados, identifico a press\u00e3o cont\u00ednua sobre a CPU, a mem\u00f3ria ou as E\/S gerada por contas individuais e planeio as realoca\u00e7\u00f5es atempadamente. Os valores baseados em cgroups mostram-me quais os servi\u00e7os afetados e onde devo limitar ou priorizar de forma espec\u00edfica. Desta forma, mantenho tempos de resposta fi\u00e1veis e garanto uma utiliza\u00e7\u00e3o justa dos recursos, mesmo sob carga. Isto reduz os custos, evita escaladas e aumenta a <strong>qualidade<\/strong>.<\/p>\n\n<h2>Conclus\u00e3o: os indicadores transformam-se em decis\u00f5es<\/h2>\n<p>Utilizo o Linux PSI porque torna os tempos de espera mensur\u00e1veis e, assim, colmata a lacuna entre a carga do sistema e a experi\u00eancia do utilizador. Com o \u00absome\u00bb deteto sinais precoces, com o \u00abfull\u00bb reajo a bloqueios reais e, com os Cgroups, identifico as causas exatas. Os pain\u00e9is, os gatilhos e as linhas de base transformam esta vis\u00e3o em medidas concretas: limites otimizados, melhor distribui\u00e7\u00e3o de carga, percursos de E\/S limpos. Quem utiliza ativamente o PSI reduz o tempo necess\u00e1rio para identificar a causa e evita muitas itera\u00e7\u00f5es de afina\u00e7\u00e3o \u00e0s cegas. Assim, os dados de monitoriza\u00e7\u00e3o transformam-se em <strong>Decis\u00f5es<\/strong>, que tornam os sistemas visivelmente mais r\u00e1pidos.<\/p>","protected":false},"excerpt":{"rendered":"<p>O Linux PSI (Pressure Stall Information) mostra em que medida a CPU, a mem\u00f3ria e as E\/S est\u00e3o a limitar o desempenho do teu sistema. Descobre como ativar o PSI e como utiliz\u00e1-lo para uma monitoriza\u00e7\u00e3o precisa do desempenho.<\/p>","protected":false},"author":1,"featured_media":21240,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-21247","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"99","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Linux PSI","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21240","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21247","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=21247"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21247\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21240"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21247"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21247"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21247"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}