{"id":21483,"date":"2026-09-17T11:51:02","date_gmt":"2026-09-17T09:51:02","guid":{"rendered":"https:\/\/webhosting.de\/linux-vmstat-richtig-interpretieren-performanceanalyse-monitoring\/"},"modified":"2026-09-17T11:51:02","modified_gmt":"2026-09-17T09:51:02","slug":"interpretar-corretamente-o-vmstat-no-linux-analise-de-desempenho-e-monitorizacao","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/linux-vmstat-richtig-interpretieren-performanceanalyse-monitoring\/","title":{"rendered":"Interpretar corretamente o vmstat no Linux para uma an\u00e1lise eficaz do desempenho"},"content":{"rendered":"<p>Vou mostrar-te como interpretar o vmstat no Linux de forma eficaz: conseguir\u00e1s identificar gargalos da CPU, press\u00e3o na mem\u00f3ria, swap e tempos de espera de E\/S em poucos segundos. \u00c9 assim que interpretas com seguran\u00e7a as colunas r, b, free, si\/so, bi\/bo e us\/sy\/id\/wa\/st e deduzes medidas concretas a partir dos padr\u00f5es observados \u2013 sem adivinhar, com <strong>claro<\/strong> Regras.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<ul>\n  <li><strong>Fila de execu\u00e7\u00e3o<\/strong> vs. Bloqueios: \u00abr\u00bb indica a carga da CPU, \u00abb\u00bb avisa sobre tempos de espera de E\/S.<\/li>\n  <li><strong>Mem\u00f3ria<\/strong> Avaliar de forma realista: o facto de ser gratuito, por si s\u00f3, n\u00e3o conta; o que importa \u00e9 o resultado.<\/li>\n  <li><strong>E\/S<\/strong> Em destaque: o bi\/bo n\u00e3o s\u00e3o cr\u00edticos, desde que o wa se mantenha baixo.<\/li>\n  <li><strong>Quotas de mercado da CPU<\/strong> interpretar: us+sy elevado, id baixo \u2192 elevada carga de trabalho.<\/li>\n  <li><strong>Linhas de base<\/strong> criar: comparar os valores do quotidiano com as fases problem\u00e1ticas.<\/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-vmstat-analyse-9847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>O que \u00e9 que o vmstat realmente mostra?<\/h2>\n\n<p>O vmstat re\u00fane os estados dos processos, a mem\u00f3ria, o espa\u00e7o de swap, as E\/S de bloco e as percentagens de utiliza\u00e7\u00e3o da CPU numa sa\u00edda compacta, que, em segundos, fornece um <strong>a n\u00edvel do sistema<\/strong> D\u00e1 uma boa ideia. Primeiro, leio \u201eprocs\u201c para r\/b, depois \u201ememory\/swap\u201c para free, buff, cache e si\/so. Em seguida, verifico \u201eio\u201c com bi\/bo e termino com \u201ecpu\u201c para us, sy, id, wa e, opcionalmente, st. Esta ordem ajuda-me a distinguir causa e efeito: um valor elevado de r indica carga computacional, um valor elevado de b aponta para tempos de espera de E\/S, e wa associa a inatividade da CPU \u00e0 lat\u00eancia de E\/S. Assim, consigo identificar se o problema est\u00e1 no trabalho de processamento, na escassez de mem\u00f3ria ou no dispositivo de armazenamento \u2013 e poupo-me <strong>Desvios<\/strong>.<\/p>\n\n<h2>In\u00edcio em 60 segundos: chamadas e intervalos<\/h2>\n\n<p>Para obter um instant\u00e2neo desde o arranque, executo o \u201evmstat\u201c sem par\u00e2metros; para an\u00e1lises imediatas, utilizo o \u201evmstat 1\u201c ou o \u201evmstat 5 12\u201c para doze pontos de medi\u00e7\u00e3o a cada cinco segundos e obtenho um <strong>temporal<\/strong> Linha. Importante: a primeira linha reflete os valores m\u00e9dios desde o arranque do sistema; por isso, analiso sobretudo as linhas seguintes. Com \u201eDelay\/Count\u201c, controlo a frequ\u00eancia de amostragem e a dura\u00e7\u00e3o, por exemplo, \u00abvmstat 1 30\u00bb em picos curtos. Em cargas de trabalho inst\u00e1veis, defino 1\u20132 segundos; em cen\u00e1rios mais calmos, prefiro 5 segundos. Observo tend\u00eancias, n\u00e3o fotogramas isolados, porque os padr\u00f5es revelam o verdadeiro <strong>Causas<\/strong> espet\u00e1culo.<\/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\/vmstat_performance_4567.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Compreender os processos: r e b no dia a dia<\/h2>\n\n<p>A coluna \u00abr\u00bb mostra os threads prontos a executar que est\u00e3o \u00e0 espera de tempo de CPU; a coluna \u00abb\u00bb conta os threads bloqueados, muitas vezes em espera de E\/S. Se o valor de \u00abr\u00bb se mantiver significativamente acima do n\u00famero de n\u00facleos f\u00edsicos, \u00e9 inevit\u00e1vel que <strong>Limita\u00e7\u00e3o da CPU<\/strong> ; em quatro n\u00facleos, um valor de r=8 durante um per\u00edodo prolongado \u00e9 considerado um sinal claro. Um valor de b superior a 0 durante um per\u00edodo prolongado indica suportes de dados lentos, bases de dados sobrecarregadas ou percursos de rede ou de armazenamento lentos. Estabele\u00e7o uma correla\u00e7\u00e3o entre r, us+sy e id: se o id for baixo e o r for elevado, a CPU est\u00e1 a ter dificuldades; se o wa for elevado e o b for elevado, a E\/S est\u00e1 a causar um estrangulamento. \u00c9 assim que decido se devo escalar a pot\u00eancia de computa\u00e7\u00e3o, otimizar as consultas ou o <strong>Sistema de armazenamento<\/strong> verificar.<\/p>\n\n<h2>Interpretar as mem\u00f3rias: free, buff, cache, swpd<\/h2>\n\n<p>Um valor baixo de \u00abfree\u00bb \u00e9 normal no Linux, uma vez que o kernel utiliza a RAM de forma intensiva como cache, o que acelera o acesso aos ficheiros e proporciona um verdadeiro <strong>Rendimento<\/strong> traz. Por isso, presto mais aten\u00e7\u00e3o ao swpd e aos fluxos de swap si\/so do que apenas ao free. Um cache elevado \u00e9 bom, desde que o si\/so se mantenha quase sempre a 0; s\u00f3 um movimento cont\u00ednuo de swap indica press\u00e3o real. Se, al\u00e9m disso, ocorrer lat\u00eancia ou mesmo OOM, intervenho: aumente a RAM, reduza os processos atempadamente ou ajuste os tamanhos da cache e da JVM. O contexto continua a ser importante: a carga de trabalho, a capacidade de mem\u00f3ria e a disposi\u00e7\u00e3o NUMA determinam o que, no seu ambiente, \u00e9 considerado <strong>saud\u00e1vel<\/strong> aplica-se.<\/p>\n\n<h2>Atividade de swap: classificar de uma forma ou de outra<\/h2>\n\n<p>As colunas \u00absi\/so\u00bb medem o fluxo cont\u00ednuo entre a RAM e a \u00e1rea de troca em KB\/s e revelam a press\u00e3o real sobre a mem\u00f3ria, e n\u00e3o apenas a percebida <strong>Car\u00eancia<\/strong>. Picos de curta dura\u00e7\u00e3o s\u00e3o normais, por exemplo, quando p\u00e1ginas raramente utilizadas s\u00e3o transferidas para a mem\u00f3ria de paging. A situa\u00e7\u00e3o torna-se cr\u00edtica quando esses valores permanecem permanentemente acima de 0; isso abranda tudo, uma vez que cada transfer\u00eancia para a mem\u00f3ria de paging gera custos adicionais de E\/S. Valores elevados de \u00abso\u00bb indicam uma transfer\u00eancia ativa para a mem\u00f3ria de paging, e os tempos de resposta aumentam significativamente. Nesta altura, procuro identificar as causas: reduzir o consumo de mem\u00f3ria, aumentar a RAM ou otimizar servi\u00e7os que consomem muita mem\u00f3ria <strong>sintonizar<\/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\/vmstat-linux-performance-analysis-6234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Compreender a E\/S em bloco: bi e bo<\/h2>\n\n<p>Com o bi\/bo, consigo determinar a taxa de leitura e escrita em blocos por segundo, mas, sem contexto, n\u00e3o a avalio; o que \u00e9 decisivo \u00e9 a intera\u00e7\u00e3o com <strong>wa<\/strong>. Valores elevados de bi\/bo, juntamente com um valor elevado de wa, indicam que o armazenamento n\u00e3o est\u00e1 a acompanhar o ritmo. Quando se verifica um valor elevado de bi numa base de dados, verifico os perfis de consulta e os acertos na cache antes de substituir o hardware. Para uma an\u00e1lise mais aprofundada dos tempos de resposta, recorro ao iostat e analiso o comprimento das filas e as lat\u00eancias, para que eu <a href=\"https:\/\/webhosting.de\/pt\/server-io-wait-analyse-iostat-vmstat-metrics-disk\/\">Analisar a espera de E\/S<\/a> e possa resolver os estrangulamentos de forma espec\u00edfica. S\u00f3 quando o wa se mantiver baixo, mas o bi\/bo disparar de forma sustentada, \u00e9 que penso em <strong>Escalonamento<\/strong> do sistema de armazenamento.<\/p>\n\n<h2>Componentes da CPU: us, sy, id, wa, st<\/h2>\n\n<p>Valores elevados de us com valores baixos de wa indicam trabalho \u00fatil produtivo, enquanto valores elevados de sy sugerem uma sobrecarga significativa do kernel, como in\u00fameras pequenas opera\u00e7\u00f5es de E\/S ou muitas <strong>Mudan\u00e7a de contexto<\/strong>. Se o id for pr\u00f3ximo de 0 e se mantiver nesse valor, a CPU est\u00e1 a funcionar no limite; combinado com um valor elevado de r, isso indica uma carga computacional elevada. Se o wa aumentar, a CPU est\u00e1 \u00e0 espera de E\/S \u2013 neste caso, o ajuste fino do armazenamento costuma trazer mais benef\u00edcios do que as atualiza\u00e7\u00f5es da CPU. Nas m\u00e1quinas virtuais, presto aten\u00e7\u00e3o ao st (steal): valores elevados de st indicam que o hipervisor est\u00e1 a desviar tempo de CPU, pelo que discuto a utiliza\u00e7\u00e3o do anfitri\u00e3o com o operador. Avalio sempre us+sy como uma soma, pois esta mostra a atividade <strong>Trabalho<\/strong> no sistema.<\/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\/vmstat_linux_perf_Bild_7392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Refer\u00eancia r\u00e1pida: colunas e valores de refer\u00eancia<\/h2>\n\n<p>Utilizo a tabela seguinte como um resumo pr\u00e1tico quando analiso os resultados do vmstat para uma primeira <strong>Avalia\u00e7\u00e3o<\/strong> leitura aleat\u00f3ria.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Coluna<\/th>\n      <th>Significado<\/th>\n      <th>Em que \u00e9 que presto aten\u00e7\u00e3o<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>r<\/td>\n      <td>Threads prontos a ser executados<\/td>\n      <td>Permanente &gt; N\u00facleos \u2192 <strong>Press\u00e3o da CPU<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>b<\/td>\n      <td>T\u00f3picos bloqueados<\/td>\n      <td>Constante &gt; 0 + wa elevado \u2192 Problema de E\/S<\/td>\n    <\/tr>\n    <tr>\n      <td>livre<\/td>\n      <td>RAM gr\u00e1tis<\/td>\n      <td>Um valor baixo n\u00e3o faz mal, desde que si\/so se mantenha \u2248 0<\/td>\n    <\/tr>\n    <tr>\n      <td>buff\/cache<\/td>\n      <td>Buffer FS\/Cache de p\u00e1ginas<\/td>\n      <td>Ter muito cache \u00e9 bom; pode ser publicado <strong>tornar-se<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>si\/so<\/td>\n      <td>Troca de entrada\/sa\u00edda<\/td>\n      <td>Valor cont\u00ednuo &gt; 0 \u2192 press\u00e3o real no reservat\u00f3rio<\/td>\n    <\/tr>\n    <tr>\n      <td>bi\/bo<\/td>\n      <td>E\/S em bloco<\/td>\n      <td>S\u00f3 \u00e9 cr\u00edtico se o \u00abwa\u00bb tamb\u00e9m for elevado<\/td>\n    <\/tr>\n    <tr>\n      <td>us\/sy<\/td>\n      <td>Utilizador\/N\u00facleo<\/td>\n      <td>us+sy de forma cont\u00ednua &gt; 80% \u2192 elevado <strong>Carga<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>id<\/td>\n      <td>marcha lenta<\/td>\n      <td>Pr\u00f3ximo de 0 ao longo do tempo \u2192 CPU saturada<\/td>\n    <\/tr>\n    <tr>\n      <td>wa<\/td>\n      <td>Espera de E\/S<\/td>\n      <td>Valor elevado com \u00abb\u00bb elevado \u2192 Armazenamento como causa<\/td>\n    <\/tr>\n    <tr>\n      <td>st<\/td>\n      <td>Roubar (m\u00e1quinas virtuais)<\/td>\n      <td>Elevado \u2192 O hipervisor ocupa <strong>CPU<\/strong>-Hora<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Valores de refer\u00eancia e monitoriza\u00e7\u00e3o cont\u00ednua<\/h2>\n\n<p>N\u00e3o me baseio em dados pontuais, mas sim comparo esses valores com valores de refer\u00eancia de per\u00edodos mais calmos, para poder identificar claramente os valores at\u00edpicos <strong>reconhecer<\/strong>. O comando \u201evmstat 1 60\u201c fornece-me um perfil de carga de um minuto, que comparo com fases normais conhecidas. Para uma perspetiva hist\u00f3rica, utilizo <a href=\"https:\/\/webhosting.de\/pt\/sar-sysstat-monitorizacao-de-servidores-linux\/\">Monitoriza\u00e7\u00e3o sar\/sysstat<\/a>, para avaliar tend\u00eancias ao longo de v\u00e1rios dias e afinar os valores-limite. Defino os alertas de forma conservadora: r em rela\u00e7\u00e3o aos n\u00facleos, si\/so diferente de 0 ao longo de v\u00e1rios intervalos, wa significativamente elevado. Assim, reajo atempadamente, antes de os utilizadores reportarem atrasos e antes de <strong>Pico<\/strong>-As fases agravam-se.<\/p>\n\n<h2>O vmstat em conjunto com outras ferramentas<\/h2>\n\n<p>Come\u00e7o pelo vmstat, analiso os padr\u00f5es e aprofundo a an\u00e1lise de forma espec\u00edfica com o iostat, o mpstat, o pidstat ou m\u00e9tricas de aplica\u00e7\u00f5es, para identificar as causas <strong>claro<\/strong> atribuir. O vmstat mostra os tempos de espera de E\/S; com o iostat, medo as lat\u00eancias e as filas por dispositivo. Se \u00abr\u00bb indicar um limite do n\u00facleo, o mpstat revela assimetrias do n\u00facleo. Em picos de carga dos processos, fornece <a href=\"https:\/\/webhosting.de\/pt\/pidstat-linux-analise-de-processos-monitorizacao\/\">An\u00e1lise de processos pidstat<\/a> os t\u00f3picos mais acalorados sobre o tempo. S\u00f3 a correla\u00e7\u00e3o com os registos e os tempos de execu\u00e7\u00e3o das aplica\u00e7\u00f5es \u00e9 que clarifica o quadro e me leva \u00e0 verdadeira <strong>Causa<\/strong>.<\/p>\n\n<h2>Identificar padr\u00f5es e agir<\/h2>\n\n<p>Se eu observar que r est\u00e1 alto, id baixo e wa moderado, a aplica\u00e7\u00e3o costuma otimizar de forma demasiado intensiva em termos de c\u00e1lculo, pelo que verifico o c\u00f3digo ou o paralelismo e planeio os recursos da CPU antes de <strong>Hardware<\/strong> exijo. Se os valores de b, wa e bi\/bo aparecerem em conjunto, tenho em considera\u00e7\u00e3o o ajuste do armazenamento, a otimiza\u00e7\u00e3o das consultas e o cache. Se o valor de free for baixo, com si\/so superior a 0, reduzo o consumo de mem\u00f3ria, transmito os resultados em streaming ou aumente a RAM. Se os valores de us forem moderados e os de sy muito elevados, analiso os filtros de pacotes, as op\u00e7\u00f5es do sistema de ficheiros ou os controladores. Com esta lista de verifica\u00e7\u00e3o, agi rapidamente e dedico o meu tempo onde \u00e9 mais <strong>contagens<\/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\/vmstat-linux-analyst-7645.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Evitar erros de medi\u00e7\u00e3o: amostragem, unidades, primeira linha<\/h2>\n\n<p>De forma deliberada, n\u00e3o considero a primeira linha para detetar falhas agudas, uma vez que ela calcula a m\u00e9dia desde o arranque e suaviza completamente os picos. Al\u00e9m disso, defino a frequ\u00eancia de amostragem com base na hip\u00f3tese da causa: registo picos de CPU com intervalos de 1 segundo e fugas de mem\u00f3ria lentas com intervalos de 5 a 10 segundos. Tenho em conta as unidades: si\/so correspondem a KB\/s, bi\/bo a \u201eblocos\/s\u201c (historicamente 1 KB por bloco, vari\u00e1vel consoante a vers\u00e3o do vmstat). Verifico se o comando \u201evmstat -w\u201c (sa\u00edda ampla) evita o corte de colunas e se as altera\u00e7\u00f5es na frequ\u00eancia de clock (P-States, Turbo) influenciam a perce\u00e7\u00e3o da carga a curto prazo. Sincronizo as medi\u00e7\u00f5es com os picos da aplica\u00e7\u00e3o, em vez de considerar cegamente \u201eminutos inteiros\u201c.<\/p>\n\n<h2>Descodificar a sec\u00e7\u00e3o \u00abSystem\u00bb: in e cs<\/h2>\n\n<p>Para al\u00e9m de procs\/memory\/swap\/io\/cpu, o vmstat tamb\u00e9m apresenta \u201esystem\u201c: <strong>em<\/strong> (interrup\u00e7\u00f5es\/s) e <strong>cs<\/strong> (Mudan\u00e7as de contexto\/s). Estes dois valores d\u00e3o-me muitas informa\u00e7\u00f5es sobre a sobrecarga do kernel.<\/p>\n<ul>\n  <li>cs muito elevado com carga \u00fatil moderada: oscila\u00e7\u00e3o de threads, lotes de workers demasiado pequenos ou conten\u00e7\u00e3o de bloqueios. Aumento o tamanho dos lotes, regulo o paralelismo (conjuntos de threads) e verifico os pontos cr\u00edticos do agendador e dos mutex.<\/li>\n  <li>aumentos repentinos: picos de interrup\u00e7\u00f5es de rede ou de armazenamento, efeitos NAPI\/polling ou interrup\u00e7\u00f5es de temporizador. Comparo com a percentagem de sy e os resultados do iostat para verificar os controladores ou os percursos de rede.<\/li>\n  <li>cs proporcional a r: isto aponta para uma press\u00e3o constante de mudan\u00e7a de contexto devido a um paralelismo excessivo. Vou reduzir o paralelismo ativo ou fixar os Hot-Threads aos n\u00facleos.<\/li>\n<\/ul>\n<p>Correlaciono sempre in\/cs com sy e b\/wa: s\u00f3 em conjunto \u00e9 que se obt\u00e9m uma imagem clara sobre se o trabalho do kernel \u00e9 \u00fatil (por exemplo, d\u00e9bito) ou se constitui apenas sobrecarga.<\/p>\n\n<h2>Variantes e op\u00e7\u00f5es \u00fateis do vmstat<\/h2>\n\n<p>Utilizo o vmstat de forma flex\u00edvel para obter perspetivas adicionais sem ter de mudar de ferramenta:<\/p>\n<ul>\n  <li><strong>vmstat -s<\/strong>: Contadores de soma (por exemplo, processos iniciados desde o arranque, falhas de p\u00e1gina principais\/secund\u00e1rias). Ideal para comparar fugas ou n\u00fameros de casos ao longo de intervalos de tempo.<\/li>\n  <li><strong>vmstat -m<\/strong>: Utiliza\u00e7\u00e3o de Slab \u2013 ajuda a classificar as caches do kernel (Dentry\/Inode, rede) como consumidores de RAM.<\/li>\n  <li><strong>vmstat -d<\/strong>: Eventos de disco ao n\u00edvel dos totais. N\u00e3o substitui o iostat, mas \u00e9 \u00fatil para uma verifica\u00e7\u00e3o r\u00e1pida da situa\u00e7\u00e3o real.<\/li>\n  <li><strong>vmstat -S M<\/strong>: Alterar as unidades (M\/K) para facilitar a leitura dos n\u00fameros.<\/li>\n  <li><strong>vmstat -w<\/strong>: Colunas mais largas evitam que os n\u00fameros sejam cortados em colunas com muitos n\u00fameros.<\/li>\n<\/ul>\n<p>Combino estas op\u00e7\u00f5es com intervalos curtos, para n\u00e3o perder nenhum evento e, mesmo assim, manter uma vis\u00e3o geral.<\/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\/vmstat_linux_analyse_3947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Containers, m\u00e1quinas virtuais e cgroups: particularidades<\/h2>\n\n<p>Nos contentores, interpreto o vmstat com cautela: muitos dados do kernel s\u00e3o v\u00e1lidos para todo o host, enquanto os limites prov\u00eam dos Cgroups. Valores elevados de r num contentor refletem a perspetiva do namespace, mas o tempo real de CPU pode estar limitado pela quota de CPU\/quotas de CPU. Eu baseio-me <strong>st<\/strong> (Steal) nas m\u00e1quinas virtuais: um valor elevado de st significa que o hipervisor me retira tempo \u2013 nesse caso, mesmo uma otimiza\u00e7\u00e3o perfeita da aplica\u00e7\u00e3o pouco ajuda, desde que o anfitri\u00e3o esteja sobrecarregado. No caso de limites de mem\u00f3ria em Cgroups, o si\/so pode deixar de funcionar, apesar de o contentor estar a \u201eagitar-se\u201c no limite (termina\u00e7\u00f5es OOM em vez de swap). Por isso, verifico adicionalmente os registos OOM e as estat\u00edsticas do Cgroup e comparo as imagens do vmstat com os limites.<\/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\/vmstat-linux-analyst-7645.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NUMA e afinidade: quando a localiza\u00e7\u00e3o \u00e9 importante<\/h2>\n\n<p>Em hosts NUMA, verifico os valores de r e us\/sy por n\u00facleo (com o mpstat) e observo se determinados sockets ficam \u201esobrecarregados\u201c, enquanto outros permanecem inativos. Uma localiza\u00e7\u00e3o inadequada da mem\u00f3ria leva a aumentos nos valores de cs\/sy e b\/wa, devido a acessos \u00e0 mem\u00f3ria distantes. Testo a afinidade da CPU e da mem\u00f3ria (cpuset, numactl), configuro grandes heaps como \u201eintercalados\u201c ou estritamente locais e certifico-me de que os threads ativos s\u00e3o executados onde se encontra a sua pegada de dados. Um layout NUMA est\u00e1vel suaviza o cs, reduz os picos de wa e aumenta a <strong>Planeamento<\/strong> sob carga.<\/p>\n\n<h2>Evitar interpreta\u00e7\u00f5es erradas: o wa e o b s\u00e3o mais do que \u201esuportes de dados lentos\u201c<\/h2>\n\n<p>O wa n\u00e3o aumenta apenas devido \u00e0s lat\u00eancias cl\u00e1ssicas do disco: tamb\u00e9m o NFS\/rede de alta lat\u00eancia, o armazenamento de objetos saturado, os volumes na nuvem que causam bloqueios ou os writebacks lentos da cache de p\u00e1ginas fazem com que o wa aumente. O b conta as tarefas em estado de suspens\u00e3o ininterrupta (D-State) \u2013 o que inclui tamb\u00e9m bloqueios em controladores, percursos de rede ou bloqueios do sistema de ficheiros. Por isso, nunca avalio o wa\/b isoladamente, mas sempre em conjunto com o bi\/bo e os tempos de resposta das aplica\u00e7\u00f5es. Se o wa estiver elevado, mas o bi\/bo baixo, isso indica frequentemente uma <strong>Depend\u00eancia da espera<\/strong> para al\u00e9m da mera quest\u00e3o do d\u00e9bito dos dispositivos (por exemplo, bloqueio, E\/S remota, congestionamento de writeback).<\/p>\n\n<h2>Otimiza\u00e7\u00e3o com bom senso: Swappiness, Writeback, Scheduler<\/h2>\n\n<p>S\u00f3 alterei o Kernel-Tuner ap\u00f3s ter efetuado medi\u00e7\u00f5es e com um plano de revers\u00e3o:<\/p>\n<ul>\n  <li><strong>vm.swappiness<\/strong>: Um valor baixo reduz a troca proativa de p\u00e1ginas, o que \u00e9 bom para aplica\u00e7\u00f5es em que a lat\u00eancia \u00e9 cr\u00edtica \u2013 um valor demasiado baixo pode aumentar a press\u00e3o na cache de p\u00e1ginas.<\/li>\n  <li><strong>vm.dirty_background_ratio \/ vm.dirty_ratio<\/strong> (ou *_bytes): Influenciam os momentos de writeback. Valores demasiado elevados provocam longas rajadas de escrita (picos de wa), enquanto valores demasiado baixos aumentam os pequenos flushes constantes (sy\/bo aumentam).<\/li>\n  <li><strong>Agendador de E\/S\/Profundidade da fila<\/strong>: Configura\u00e7\u00f5es diferentes do Optima em NVMe do que em HDD\/RAID. Medei os compromissos entre lat\u00eancia e d\u00e9bito com o iostat antes de fazer qualquer altera\u00e7\u00e3o.<\/li>\n  <li><strong>Caminhos de rede<\/strong>: Muitos pequenos pacotes\/interrup\u00e7\u00f5es chegam a \/cs\/sy. Os principais par\u00e2metros de ajuste s\u00e3o GRO\/LRO, RPS\/RFS e IRQ-Affinity \u2013 fa\u00e7o medi\u00e7\u00f5es antes e depois.<\/li>\n<\/ul>\n<p>O meu objetivo \u00e9 obter curvas est\u00e1veis e previs\u00edveis no vmstat: us\/sy mais est\u00e1veis, wa\/b mais baixos e si\/so pr\u00f3ximos de 0. S\u00f3 ent\u00e3o \u00e9 que procuro aumentar a capacidade do hardware.<\/p>\n\n<h2>Guia pr\u00e1tico: An\u00e1lise de 3 minutos com o vmstat<\/h2>\n\n<ul>\n  <li>0:00\u20130:30 \u2013 \u201evmstat 1 30\u201c: ignorar a primeira linha e, em seguida, analisar r\/b, us\/sy\/id\/wa. Pergunta: limite da CPU (r elevado, id baixo) ou limite de E\/S (b\/wa elevados)?<\/li>\n  <li>0:30\u20131:00 \u2013 Vis\u00e3o geral do acumulador: verificar swpd e si\/so. si\/so constantemente &gt; 0? \u2192 press\u00e3o real no acumulador. free \u00e9 secund\u00e1rio.<\/li>\n  <li>1:00\u20131:30 \u2013 Contexto de E\/S: bi\/bo vs. wa. Valores elevados de bi\/bo sem wa? \u2192 A E\/S \u00e9 desligada. Valores elevados de wa com bi\/bo moderados? \u2192 Lat\u00eancia\/bloqueio\/E\/S remota.<\/li>\n  <li>1:30\u20132:00 \u2013 Sec\u00e7\u00e3o \u00absystem\u00bb: in\/cs em rela\u00e7\u00e3o a sy. cs muito elevado? \u2192 Verificar press\u00e3o de mudan\u00e7a de contexto, paralelismo\/bloqueio.<\/li>\n  <li>2:00\u20133:00 \u2013 Confirmar a hip\u00f3tese e selecionar a ferramenta adequada: iostat para o \u00edndice de E\/S, mpstat para assimetrias do n\u00facleo, pidstat para pontos cr\u00edticos dos processos. S\u00f3 depois \u00e9 que se procede ao ajuste\/dimensionamento.<\/li>\n<\/ul>\n\n<h2>Exemplos avan\u00e7ados retirados da pr\u00e1tica<\/h2>\n\n<ul>\n  <li><strong>Satura\u00e7\u00e3o da CPU sem um r elevado<\/strong>: us+sy em 90%+, id \u2248 0, mas r moderado \u2192 ponto cr\u00edtico de thread \u00fanico ou problema de afinidade. Solu\u00e7\u00e3o: paralelizar o caminho cr\u00edtico, verificar o core-pinning.<\/li>\n  <li><strong>Swap-Thrash<\/strong>: em ambos os casos, simultaneamente, valores claramente &gt; 0, b\/wa aumentam, us diminui \u2192 RAM claramente insuficiente ou heap mal dimensionado. Medidas: aumentar a RAM, reduzir o conjunto de trabalho, ajustar a swappiness.<\/li>\n  <li><strong>Sobrecarga do kernel<\/strong>: sy elevado, cs\/in elevado, us moderado \u2192 muitas pequenas chamadas de sistema\/E\/S. Solu\u00e7\u00e3o: processamento em lote, redu\u00e7\u00e3o das chamadas de sistema, verificar as op\u00e7\u00f5es de montagem do sistema de ficheiros.<\/li>\n  <li><strong>Atraso na reverte<\/strong>: wa elevado, bo elevado, ondas curtas \u2192 limites de \u00abdirty\u00bb demasiado elevados, lat\u00eancia de armazenamento vari\u00e1vel. Verificar o ajuste do \u00abwriteback\u00bb e o agendador de E\/S.<\/li>\n  <li><strong>Press\u00e3o da virtualiza\u00e7\u00e3o<\/strong>: st vis\u00edvel, r oscila, id \u201esalta\u201c \u2192 O anfitri\u00e3o partilha a CPU. Solu\u00e7\u00e3o: verificar a atribui\u00e7\u00e3o\/coloca\u00e7\u00e3o da vCPU, reduzir o overcommit.<\/li>\n<\/ul>\n\n<h2>Conhecer os limites do vmstat<\/h2>\n\n<p>O vmstat \u00e9 um excelente <strong>Sensor de alerta precoce<\/strong>, mas n\u00e3o \u00e9 um microsc\u00f3pio. Mostra-me que e onde est\u00e1 o problema \u2013 n\u00e3o o ficheiro espec\u00edfico, a consulta ou o thread. \u00c9 por isso que, ap\u00f3s o diagn\u00f3stico com o vmstat, recorro sistematicamente a ferramentas mais aprofundadas, confirmo hip\u00f3teses a partir de v\u00e1rias perspetivas e, depois, altero apenas uma coisa de cada vez. Desta forma, as melhorias permanecem mensur\u00e1veis e reproduz\u00edveis.<\/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\/vmstat_linux_analyse_3947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Resumo da pr\u00e1tica<\/h2>\n\n<p>Com o vmstat, consigo perceber em segundos se \u00e9 a CPU, a RAM, o swap ou a E\/S que est\u00e1 a causar o atraso, analisando a intera\u00e7\u00e3o entre r, b, si\/so, bi\/bo e us\/sy\/id\/wa\/st <strong>ler<\/strong>. Avalio tend\u00eancias em vez de valores individuais, comparo com valores de refer\u00eancia e, se necess\u00e1rio, recorro ao iostat, ao mpstat, ao pidstat e a medi\u00e7\u00f5es hist\u00f3ricas. Ignoro a primeira linha no caso de falhas agudas e concentro-me nas linhas seguintes, com uma taxa de amostragem fixa. Tomo decis\u00f5es com base nos dados: r em rela\u00e7\u00e3o aos n\u00facleos, si\/so permanentemente diferentes de 0, wa persistentemente elevado, us+sy pr\u00f3ximos da carga m\u00e1xima. Assim, deduzo rapidamente medidas concretas e mantenho os sistemas visivelmente <strong>reativo<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Aprenda a interpretar corretamente o comando vmstat no Linux para identificar gargalos na CPU, na mem\u00f3ria e nas E\/S e otimizar a sua an\u00e1lise de desempenho com a palavra-chave \u00abvmstat linux\u00bb.<\/p>","protected":false},"author":1,"featured_media":21476,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-21483","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":"86","_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":"vmstat linux","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":"21476","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21483","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=21483"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21483\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21476"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21483"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21483"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21483"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}