{"id":20212,"date":"2026-08-01T08:32:36","date_gmt":"2026-08-01T06:32:36","guid":{"rendered":"https:\/\/webhosting.de\/memory-pressure-linux-kernel-hosting-systeme-optimierung-ram\/"},"modified":"2026-08-01T08:32:36","modified_gmt":"2026-08-01T06:32:36","slug":"pressao-de-memoria-kernel-do-linux-sistemas-de-alojamento-otimizacao-ram","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/memory-pressure-linux-kernel-hosting-systeme-optimierung-ram\/","title":{"rendered":"Press\u00e3o de mem\u00f3ria no kernel do Linux: impacto nos sistemas de alojamento"},"content":{"rendered":"<p>A press\u00e3o de mem\u00f3ria no kernel do Linux afeta diretamente os sistemas de alojamento: \u00e0 medida que a press\u00e3o aumenta, o tempo de CPU e as opera\u00e7\u00f5es de E\/S s\u00e3o desviados para tarefas mais exigentes <strong>Reclaim<\/strong>, os tempos de resposta aumentam e os riscos de OOM crescem. Vou explicar claramente como identifico, avalio e resolvo a press\u00e3o sobre a mem\u00f3ria, para que <strong>Hospedagem<\/strong>- Reagir de forma constante \u00e0s cargas de trabalho.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<p>Concentro-me nos fatores-chave que determinam o desempenho e as falhas em ambientes de alojamento. Os pontos seguintes constituem o fio condutor que orienta o meu diagn\u00f3stico e a minha otimiza\u00e7\u00e3o. Com esta vis\u00e3o geral, evito interpreta\u00e7\u00f5es erradas de \u201eRAM cheia\u201c e identifico os verdadeiros <strong>Press\u00e3o<\/strong> atempadamente.<\/p>\n<ul>\n  <li><strong>M\u00e9tricas PSI<\/strong> mostram os tempos de espera em vez da mera ocupa\u00e7\u00e3o e detetam atempadamente os atrasos.<\/li>\n  <li><strong>Carga de swap<\/strong> indica problemas de recupera\u00e7\u00e3o que agravam as opera\u00e7\u00f5es de E\/S e as lat\u00eancias.<\/li>\n  <li><strong>Limites dos cgroups<\/strong> controlar a limita\u00e7\u00e3o, a prote\u00e7\u00e3o e o comportamento em caso de OOM por servi\u00e7o.<\/li>\n  <li><strong>Deslocamento da cache<\/strong> afeta diretamente o desempenho da Web e das bases de dados.<\/li>\n  <li><strong>Planeamento de capacidades<\/strong> e o ajuste mant\u00eam a margem din\u00e2mica e evitam o thrashing.<\/li>\n<\/ul>\n<p>\u00c9 assim que estruturo as minhas an\u00e1lises, desde o kernel at\u00e9 \u00e0 aplica\u00e7\u00e3o, e implemento as medidas adequadas por ordem de prioridade. O foco mant\u00e9m-se nos resultados mensur\u00e1veis <strong>efeitos<\/strong>, e n\u00e3o ao trabalho por presta\u00e7\u00f5es.<\/p>\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\/08\/serverraum-memorydruck-4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>O que significa \u00abMemory Pressure\u00bb no kernel do Linux?<\/h2>\n\n<p>A \u201epress\u00e3o na mem\u00f3ria\u201c significa que o kernel dedica um tempo consider\u00e1vel a libertar mem\u00f3ria, em vez de dar continuidade ao trabalho dos processos do utilizador; a CPU passa ent\u00e3o a dedicar-se cada vez mais a opera\u00e7\u00f5es de leitura, grava\u00e7\u00e3o e evic\u00e7\u00e3o, enquanto as solicita\u00e7\u00f5es ficam em espera. Fa\u00e7o uma distin\u00e7\u00e3o clara entre \u201eRAM cheia\u00bb e \u00abfalta de mem\u00f3ria utiliz\u00e1vel\u00bb <strong>espa\u00e7o livre<\/strong>\u201c: Um cache \u201echeio\u201c \u00e9 saud\u00e1vel; os estrangulamentos s\u00f3 surgem quando os investimentos em recupera\u00e7\u00e3o aumentam. O kernel analisa as listas inativas, grava <strong>sujo<\/strong>-elimina p\u00e1ginas, limpa a cache de ficheiros e transfere p\u00e1ginas an\u00f3nimas para o armazenamento externo assim que os valores de marca d'\u00e1gua s\u00e3o ultrapassados. O tempo gasto nestas atividades \u00e9 determinante; reflete-se nos per\u00edodos de espera das tarefas e nos tempos de resposta prolongados. Um host pode funcionar de forma silenciosa com uma utiliza\u00e7\u00e3o de 95 %, desde que o cache seja facilmente recuper\u00e1vel, mas pode ficar gravemente bloqueado em condi\u00e7\u00f5es de baixa utiliza\u00e7\u00e3o, quando as p\u00e1ginas an\u00f3nimas ativas t\u00eam de ser substitu\u00eddas.<\/p>\n\n<h2>Compreender e medir o PSI<\/h2>\n\n<p>A \u00abPressure Stall Information\u00bb (PSI) torna a press\u00e3o na mem\u00f3ria tang\u00edvel, porque n\u00e3o medo a ocupa\u00e7\u00e3o, mas sim os atrasos. Em <strong>\/proc\/pressure\/memory<\/strong> Vejo \u201esome\u201c e \u201efull\u201c: \u201esome\u201c descreve momentos em que pelo menos uma tarefa est\u00e1 \u00e0 espera de mem\u00f3ria, enquanto \u201efull\u201c indica fases em que todas as tarefas est\u00e3o paralisadas. Exemplo: \u201esome avg10=4,67\u201c significa que, nos \u00faltimos 10 segundos, 4,67 % do tempo foram ocupados por bloqueios devido a estrangulamentos de mem\u00f3ria; \u201efull avg10=0,30\u201c indica bloqueios totais raros. Correlaciono precocemente os valores crescentes de \u201esome\u201c com os tempos de resposta e procuro dimensionar, otimizar ou aliviar a carga antes que surjam erros graves de OOM. Esta perspetiva impede-me de me deixar enganar por uma RAM aparentemente \u201ecom muita mem\u00f3ria livre\u201c, pois as p\u00e1ginas livres sem acesso r\u00e1pido <strong>Reclaim<\/strong>-Aproveitam pouco essa oportunidade.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Vari\u00e1vel medida<\/th>\n      <th>Valor indicativo<\/th>\n      <th>Sintoma<\/th>\n      <th>A\u00e7\u00e3o<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Mem\u00f3ria PSI (m\u00e9dia de 10)<\/td>\n      <td>&gt; 2\u20133 % cont\u00ednuo<\/td>\n      <td>Os tempos de resposta est\u00e3o a aumentar<\/td>\n      <td>Verificar a margem de RAM, ajustar com precis\u00e3o os limites do Cgroup<\/td>\n    <\/tr>\n    <tr>\n      <td>Mem\u00f3ria PSI cheia (m\u00e9dia de 10)<\/td>\n      <td>&gt; 0,1 % percet\u00edvel<\/td>\n      <td>Tempos de inatividade curtos<\/td>\n      <td>Identificar a causa, p\u00f4r fim ao thrashing<\/td>\n    <\/tr>\n    <tr>\n      <td>MemDispon\u00edvel<\/td>\n      <td>&lt; 10 % da RAM<\/td>\n      <td>Margem reduzida<\/td>\n      <td>Aliviar a carga do cache\/trabalho, planear a capacidade<\/td>\n    <\/tr>\n    <tr>\n      <td>vmstat si\/so<\/td>\n      <td>permanente &gt; 0<\/td>\n      <td>Press\u00e3o de troca<\/td>\n      <td>Swappiness\/Ajustar swap, proteger o Hotset<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/memorypressurekonferenz3542.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sintomas em ambientes de alojamento<\/h2>\n\n<p>Em servidores com muita atividade, vejo primeiro picos de lat\u00eancia, enquanto a carga da CPU parece manter-se moderada; o kernel fica em loops de recupera\u00e7\u00e3o, a E\/S fica congestionada e as solicita\u00e7\u00f5es ficam em espera. A m\u00e9dia de carga sobe, apesar de os n\u00facleos parecerem estar livres, porque muitas tarefas ficam bloqueadas na mem\u00f3ria ou na E\/S; isto \u00e9 um sinal fundamental de aumento da <strong>Impress\u00f5es<\/strong>. Valores persistentes de si\/so no vmstat indicam que o sistema est\u00e1 a utilizar ativamente a mem\u00f3ria de swap, o que retarda os handshakes TLS, os conte\u00fados din\u00e2micos e os percursos de consulta. Se esta situa\u00e7\u00e3o n\u00e3o for resolvida, o sistema entra em \u00abthrashing\u00bb: a CPU passa a maior parte do tempo com paging e swapping, em vez de realizar tarefas \u00fateis. Nesta fase de escalada, o OOM-Killer interv\u00e9m e encerra os processos com pontua\u00e7\u00e3o elevada; uma abordagem direcionada <a href=\"https:\/\/webhosting.de\/pt\/oom-killer-linux-memoria-sem-memoria-analise-alojamento\/\">An\u00e1lise do OOM-Killer<\/a> ajuda-me a identificar padr\u00f5es e configura\u00e7\u00f5es incorretas.<\/p>\n\n<h2>Relev\u00e2ncia para cargas de trabalho de alojamento e cgroups<\/h2>\n\n<p>Em ambientes partilhados, basta uma \u00fanica aplica\u00e7\u00e3o que consuma muitos recursos de mem\u00f3ria para aumentar as lat\u00eancias para muitos clientes; os cgroups atenuam os efeitos, mas n\u00e3o resolvem o problema de uma dimensiona\u00e7\u00e3o incorreta <strong>Inst\u00e2ncias<\/strong>. Em inst\u00e2ncias VPS e na nuvem, uma mem\u00f3ria RAM insuficiente ou uma estrat\u00e9gia de swap inadequada conduzem mais rapidamente a picos de carga; o isolamento protege os outros servi\u00e7os, mas n\u00e3o o pr\u00f3prio. As bases de dados dependem de grandes conjuntos de buffers; quando o Reclaim os liberta ou o swap interv\u00e9m, os tempos de consulta aumentam e a taxa de d\u00e9bito diminui significativamente. As orquestra\u00e7\u00f5es de contentores utilizam os par\u00e2metros `memory.low`, `memory.high` e `memory.max` para proteger servi\u00e7os importantes, limitar os bloqueios e, em caso de emerg\u00eancia, encerrar-los de forma seletiva. Por isso, escolho os limites de forma consciente e monitorizo o PSI por servi\u00e7o, para poder tomar medidas corretivas atempadamente e reservar recursos para servi\u00e7os cr\u00edticos <strong>Cargas de trabalho<\/strong> manter livre.<\/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\/08\/linux-memory-pressure-hosting-4823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Estrat\u00e9gia de monitoriza\u00e7\u00e3o e m\u00e9tricas<\/h2>\n\n<p>Consulto os valores de MemAvailable, Buffers e Cached para perceber quanta mem\u00f3ria \u00e9 recuper\u00e1vel a curto prazo; os valores de MemFree, por si s\u00f3, podem induzir facilmente em erro. Ao mesmo tempo, analiso o vmstat: valores persistentes de si\/so indicam press\u00e3o de swap, o que estimula enormemente a E\/S e aumenta as lat\u00eancias; para mais informa\u00e7\u00f5es sobre o <a href=\"https:\/\/webhosting.de\/pt\/utilizacao-de-swap-desempenho-do-servidor-alojamento-optimus\/\">Utiliza\u00e7\u00e3o de swaps<\/a> Utilizo padr\u00f5es de diagn\u00f3stico comprovados. O PSI fornece-me o elemento que faltava, porque \u201esome\u201c e \u201efull\u201c quantificam os atrasos reais; emito alertas quando os limiares s\u00e3o atingidos e distingo picos de carga de estrangulamentos cr\u00f3nicos. As s\u00e9ries temporais obtidas atrav\u00e9s do sar ou da pilha de observabilidade tornam os padr\u00f5es vis\u00edveis e ajudam-me a confirmar o sucesso dos ajustes. O dmesg revela eventos OOM que indicam limites r\u00edgidos ou configura\u00e7\u00f5es incorretas; assim, construo uma imagem coerente a partir da perspetiva do kernel, do comportamento de E\/S e <strong>Aplica\u00e7\u00e3o<\/strong>.<\/p>\n\n<h2>Cargas de trabalho t\u00edpicas sob press\u00e3o<\/h2>\n\n<p>Os servidores web como o Nginx ou o Apache fornecem conte\u00fados mais lentamente quando o Reclaim e o Swap est\u00e3o a funcionar em segundo plano; as liga\u00e7\u00f5es Keep-Alive permanecem abertas por mais tempo, o que agrava as filas de espera. As pilhas de PHP e Python ocupam mem\u00f3ria RAM devido a caches de frameworks, componentes JIT e dados de sess\u00e3o; em caso de deslocamento, estes dados oscilam entre a RAM e o armazenamento, prolongando significativamente os tempos de resposta. As bases de dados perdem velocidade assim que os conjuntos de buffers diminuem ou partes deles s\u00e3o transferidas para o swap; mesmo uma lat\u00eancia adicional m\u00ednima por E\/S acumula-se quando h\u00e1 muitas <strong>Consultas<\/strong>. Os servi\u00e7os de cache, como o Redis ou o Memcached, dependem de acertos na RAM; se as \u00e1reas-chave forem transferidas para a \u00e1rea de swap, a vantagem perde-se e aumenta o risco de serem encerrados em situa\u00e7\u00f5es de carga elevada. Em todos os casos, as m\u00e9tricas de PSI e de swap fornecem as indica\u00e7\u00f5es mais claras de que a mem\u00f3ria se tornou o gargalo, e n\u00e3o a <strong>CPU<\/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\/08\/linux_kernel_memory_pressure_4092.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Otimiza\u00e7\u00e3o do sistema e par\u00e2metros do kernel<\/h2>\n\n<p>Come\u00e7o pelo vm.swappiness: uma configura\u00e7\u00e3o moderadamente reduzida evita o uso excessivo da mem\u00f3ria de swap, sem bloquear a recupera\u00e7\u00e3o necess\u00e1ria; avalio os efeitos de forma consistente com o PSI. Em seguida, otimizo o vm.dirty_ratio e os limites relacionados, para n\u00e3o desencadear longas ondas de flush e, ao mesmo tempo, n\u00e3o provocar uma enxurrada de pequenas grava\u00e7\u00f5es; ambos t\u00eam efeitos percet\u00edveis <strong>Efeitos<\/strong> em termos de lat\u00eancias. Nos Cgroups v2, defino \u00abmemory.low\u00bb para servi\u00e7os cr\u00edticos, \u00abmemory.high\u00bb para limita\u00e7\u00e3o em caso de sobrecarga e \u00abmemory.max\u00bb como limite r\u00edgido com OOMs control\u00e1veis. Presto especial aten\u00e7\u00e3o \u00e0s topologias NUMA: pode surgir press\u00e3o local, mesmo que ainda haja RAM livre a n\u00edvel global; A vincula\u00e7\u00e3o de processos e de mem\u00f3ria atenua essas armadilhas. Por fim, verifico o comportamento da cache de p\u00e1ginas; a substitui\u00e7\u00e3o desnecess\u00e1ria reduz as taxas de acerto e custa tempo diretamente em cargas de trabalho da Web e de bases de dados, o que <a href=\"https:\/\/webhosting.de\/pt\/servidor-despejo-de-cache-de-pagina-linux-memoria-impressao-otimizacao-insight\/\">Otimiza\u00e7\u00e3o da cache de p\u00e1ginas<\/a> fornece informa\u00e7\u00f5es \u00fateis.<\/p>\n\n<h2>Uma an\u00e1lise aprofundada dos percursos do Reclaim<\/h2>\n<p>Para escolher as medidas de forma acertada, fa\u00e7o a distin\u00e7\u00e3o entre <strong>kswapd<\/strong> e <strong>Recupera\u00e7\u00e3o Direta<\/strong>. O kswapd funciona de forma ass\u00edncrona quando os valores dos watermarks s\u00e3o ultrapassados para baixo; \u00e9 relativamente suave, desde que exista cache suficiente que possa ser recuperado facilmente. O Direct Reclaim interv\u00e9m de forma s\u00edncrona nos contextos de execu\u00e7\u00e3o quando os threads necessitam urgentemente de p\u00e1ginas \u2013 \u00e9 aqui que ocorrem os atrasos percet\u00edveis pelos utilizadores. Observo se a recupera\u00e7\u00e3o afeta mais a cache de ficheiros ou as p\u00e1ginas an\u00f3nimas: se o kernel libertar principalmente a cache de ficheiros, as falhas de cache aumentam; se libertar mem\u00f3ria an\u00f3nima (por exemplo, o heap), h\u00e1 risco de paragens bruscas e atividade de swap. Os mecanismos modernos de working set t\u00eam em conta as dist\u00e2ncias de refault para manter as p\u00e1ginas \u00fateis durante mais tempo; se, mesmo assim, observar muitos refaults repetidos, sei que os hotsets s\u00e3o maiores do que o espa\u00e7o dispon\u00edvel <strong>espa\u00e7o livre<\/strong> tornaram-se.<\/p>\n<p>Al\u00e9m disso, tenho em conta a compacta\u00e7\u00e3o e a desfragmenta\u00e7\u00e3o: <strong>kcompactd<\/strong> procura criar \u00e1reas cont\u00edguas, por exemplo, para grandes aloca\u00e7\u00f5es ou <strong>THP<\/strong>. Se a compacta\u00e7\u00e3o ficar para tr\u00e1s, observo um aumento da utiliza\u00e7\u00e3o da CPU no kcompactd, lat\u00eancias crescentes e um aumento da percentagem de PSI \u201efull\u201c em picos de carga. Nesses casos, muitas vezes faz mais sentido reduzir a press\u00e3o ou ajustar as pol\u00edticas de THP, em vez de simplesmente aumentar o \u201eswap\u201c.<\/p>\n\n<h2>Estrat\u00e9gias de swap em pormenor<\/h2>\n<p>O swap n\u00e3o \u00e9 um inimigo, mas sim uma ferramenta \u2013 embora, se utilizado incorretamente, possa aumentar a lat\u00eancia. Fa\u00e7o a seguinte distin\u00e7\u00e3o:<\/p>\n<ul>\n  <li><strong>Sem swap<\/strong>: Seguro contra atrasos de swap, mas arriscado em picos \u2013 os OOMs ocorrem mais cedo, o Reclaim n\u00e3o tem uma reserva de seguran\u00e7a.<\/li>\n  <li><strong>Swap moderado<\/strong> num SSD r\u00e1pido: \u00c9 bom para transferir p\u00e1ginas an\u00f3nimas pouco utilizadas para o disco; protege os conjuntos ativos na RAM, desde que os par\u00e2metros de swappiness e os limites do cgroup estejam definidos de forma adequada.<\/li>\n  <li><strong>zswap\/zram<\/strong>: A compress\u00e3o alivia a carga de E\/S; adequada para hosts com menor volume de E\/S ou como buffer contra picos de carga de curta dura\u00e7\u00e3o. Verifico a disponibilidade da CPU e a taxa de compress\u00e3o para evitar que o sistema seja limitado pela CPU.<\/li>\n<\/ul>\n<p>N\u00e3o defino o valor de swappiness como baixo de forma generalizada; em cargas de trabalho com um cache de ficheiros grande, faz sentido definir um valor de swappiness ligeiramente mais elevado, para afastar p\u00e1ginas an\u00f3nimas pouco utilizadas e manter o cache de ficheiros est\u00e1vel. Protejo os servi\u00e7os cr\u00edticos (por exemplo, bases de dados) com a op\u00e7\u00e3o `memory.low` e, se necess\u00e1rio, bloqueando os seus conjuntos ativos na RAM, para que o swap n\u00e3o afete o que n\u00e3o deve. O essencial \u00e9 que <strong>vmstat si\/so<\/strong> e o PSI diminui de forma consistente quando ajusto a estrat\u00e9gia; caso contr\u00e1rio, fa\u00e7o os ajustes necess\u00e1rios.<\/p>\n\n<h2>THP, compacta\u00e7\u00e3o e fragmenta\u00e7\u00e3o<\/h2>\n<p><strong>P\u00e1ginas enormes transparentes (THP)<\/strong> reduzem os acessos ao TLB e ajudam aplica\u00e7\u00f5es que exigem muito da CPU e consomem muita mem\u00f3ria. No entanto, sob carga elevada, provocam trabalho de compacta\u00e7\u00e3o; a op\u00e7\u00e3o \u201ealways\u201c pode, nesse caso, causar grandes paralisa\u00e7\u00f5es. Utilizo o \u201emadvise\u201c de forma seletiva para cargas de trabalho que beneficiam com isso (por exemplo, determinados motores em mem\u00f3ria) e, no caso de pilhas web sens\u00edveis \u00e0 lat\u00eancia, prefiro desativar o THP de forma seletiva ou ativ\u00e1-lo apenas atrav\u00e9s do \u00abmadvise\u00bb. Al\u00e9m disso, observo <strong>vm.compaction_proactiveness<\/strong> e verifica se a compacta\u00e7\u00e3o proativa adia a forma\u00e7\u00e3o de estagna\u00e7\u00e3o ou se a reduz efetivamente. Se as faces do THP forem frequentemente fragmentadas ou se a compacta\u00e7\u00e3o estiver a ocorrer a um ritmo acelerado, isso indica que h\u00e1 uma quantidade insuficiente de <strong>espa\u00e7o livre<\/strong> ou padr\u00f5es de aloca\u00e7\u00e3o inadequados na aplica\u00e7\u00e3o.<\/p>\n\n<h2>Armadilhas NUMA e press\u00e3o local<\/h2>\n<p>Em hosts NUMA, a \u201eRAM livre\u201c global \u00e9 enganadora: um socket pode estar sobrecarregado, enquanto outro permanece ocioso. Verifico as estat\u00edsticas NUMA e ancoo processos localmente (vincula\u00e7\u00e3o de CPU\/mem\u00f3ria), para que os conjuntos ativos permane\u00e7am pr\u00f3ximos da carga de trabalho. A recupera\u00e7\u00e3o direta num n\u00f3, apesar das reservas globais, indica desequil\u00edbrios NUMA; neste caso, as aloca\u00e7\u00f5es intercaladas para servi\u00e7os amplamente dispersos ou a vincula\u00e7\u00e3o rigorosa para cargas de trabalho monol\u00edticas s\u00e3o \u00fateis. O PSI por cgroup, combinado com as estat\u00edsticas NUMA, mostra-me se um \u00fanico n\u00f3 est\u00e1 a gerar as filas.<\/p>\n\n<h2>Medidas relacionadas com a aplica\u00e7\u00e3o<\/h2>\n\n<p>Analiso perfis de mem\u00f3ria com o ps, o top, o htop e ferramentas de perfilagem para identificar os verdadeiros devoradores de mem\u00f3ria e fugas; ao faz\u00ea-lo, observo como os conjuntos ativos (hotsets) evoluem ao longo do tempo. Escolho os caches das aplica\u00e7\u00f5es de forma consciente: se forem demasiado grandes, geram press\u00e3o; se forem demasiado pequenos, comprometem a velocidade; fa\u00e7o os ajustes com base no PSI e nos tempos de resposta, e n\u00e3o no instinto. Quando s\u00e3o detetados sinais de press\u00e3o, a aplica\u00e7\u00e3o pode libertar voluntariamente caches menos cr\u00edticos ou dados tempor\u00e1rios; assim, reduzo os bloqueios sem alterar os limites globais. Ajusto os par\u00e2metros de arranque e o ajuste do GC (por exemplo, para JVMs) de forma a que os conjuntos de trabalho se mantenham corretamente na RAM; atenuo padr\u00f5es de aloca\u00e7\u00e3o agressivos atrav\u00e9s do processamento em lotes. Tamb\u00e9m mantenho sob vigil\u00e2ncia os artefactos de compila\u00e7\u00e3o e os s\u00edmbolos de depura\u00e7\u00e3o, pois res\u00edduos ignorados t\u00eam um custo oculto <strong>Mem\u00f3ria<\/strong> e aumentam o risco de perdas de sustenta\u00e7\u00e3o posteriores.<\/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\/08\/MemoryPressureLinuxKernel1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Subtilezas do Cgroups v2 e estrat\u00e9gias OOM<\/h2>\n<p>Com o Cgroups v2, separo claramente a prote\u00e7\u00e3o, a limita\u00e7\u00e3o e os limites r\u00edgidos: <strong>mem\u00f3ria.baixa<\/strong> Reserva margem de capacidade para servi\u00e7os cr\u00edticos; o restante \u00e9 reatribu\u00eddo a grupos menos importantes. <strong>mem\u00f3ria.alta<\/strong> reduz o desempenho em caso de excedimento, atrav\u00e9s de uma limita\u00e7\u00e3o seletiva, e obriga as aplica\u00e7\u00f5es a libertar mem\u00f3ria antes que o sistema seja afetado. <strong>mem\u00f3ria.max<\/strong> \u00e9 a \u00faltima linha de defesa \u2013 se for ultrapassada, significa OOM num contexto controlado. Eu configuro <strong>PSI<\/strong> por cgroup, para que os alertas sejam acionados nos pontos onde ocorrem bloqueios; o PSI global permanece est\u00e1vel enquanto um \u00fanico servi\u00e7o entra em colapso \u2013 \u00e9 precisamente este padr\u00e3o que pretendo detetar. Juntamente com as prioridades OOM, defino regras de sacrif\u00edcio claras: os trabalhadores em lote menos importantes s\u00e3o encerrados primeiro, enquanto as APIs do n\u00facleo mant\u00eam a sua <strong>espa\u00e7o livre<\/strong>.<\/p>\n\n<h2>Virtualiza\u00e7\u00e3o: Ballooning, KSM e Overcommit<\/h2>\n<p>Em ambientes virtualizados, deparo-me com uma dupla press\u00e3o: o sistema convidado parece detetar mem\u00f3ria RAM livre, enquanto o hipervisor, atrav\u00e9s de <strong>Balonismo<\/strong> retira. Este jogo aumenta os custos de recupera\u00e7\u00e3o para ambas as partes. Mido o PSI no convidado e cruzo os dados com as m\u00e9tricas do hipervisor; se o PSI aumentar durante eventos de ballooning, a VM necessita de mais capacidade garantida ou de melhores pol\u00edticas de Cgroup no anfitri\u00e3o. <strong>KSM<\/strong> Poupa RAM atrav\u00e9s da deduplica\u00e7\u00e3o de p\u00e1ginas id\u00eanticas, mas consome recursos da CPU; em configura\u00e7\u00f5es de alojamento com muitas m\u00e1quinas virtuais semelhantes, pode valer a pena, desde que a carga adicional na CPU n\u00e3o comprometa os SLOs. S\u00f3 planeio recorrer ao overcommit (por exemplo, a atribui\u00e7\u00e3o agressiva de muitas m\u00e1quinas virtuais pequenas) com reservas fixas de SLO e uma gest\u00e3o rigorosa <strong>mem\u00f3ria.baixa<\/strong> para sistemas em que a lat\u00eancia \u00e9 um fator cr\u00edtico.<\/p>\n\n<h2>Decis\u00f5es de arquitetura na hospedagem<\/h2>\n\n<p>Apostamos na distribui\u00e7\u00e3o horizontal, para que as inst\u00e2ncias individuais sofram menos picos de carga; os conjuntos escal\u00e1veis atenuam os picos e mant\u00eam as lat\u00eancias mais baixas. Separo claramente as fun\u00e7\u00f5es: bases de dados, aplica\u00e7\u00f5es e cache recebem os seus pr\u00f3prios conjuntos de recursos, para que os processos de recupera\u00e7\u00e3o n\u00e3o provoquem efeitos secund\u00e1rios inesperados al\u00e9m dos limites do sistema. Escolho o armazenamento tendo em conta a lat\u00eancia de grava\u00e7\u00e3o, pois as limpezas de p\u00e1ginas sujas (Dirty-Page-Flushes) t\u00eam um impacto direto nos tempos de resposta; um caminho r\u00e1pido reduz sensivelmente os tempos de recupera\u00e7\u00e3o. Em clusters, prevejo reservas de RAM por n\u00f3 e controlo atrav\u00e9s de pol\u00edticas de agendamento, para que a carga e o consumo de mem\u00f3ria se mantenham distribu\u00eddos de forma mais uniforme. Automatizo o dimensionamento com limiares PSI, para que valores crescentes de \u201esome\u201c desencadeiem a\u00e7\u00f5es antes que se verifiquem travagens bruscas e <strong>Matar<\/strong>-ocorr\u00eancias.<\/p>\n\n<h2>Planeamento de capacidade e modelos de margem de manobra<\/h2>\n<p>Defino o headroom de forma mensur\u00e1vel: mantenho reservas suficientes para que o \u201esome\u201c PSI, em picos normais, permane\u00e7a abaixo de limiares definidos e para que o \u201efull\u201c praticamente n\u00e3o ocorra. Para isso, utilizo percentis (por exemplo, o 99.\u00ba percentil da carga hor\u00e1ria) e planeio 10\u201330 % de RAM adicional, dependendo da volatilidade da carga de trabalho. As bases de dados recebem reservas fixas maiores, enquanto os front-ends web escalam de forma mais din\u00e2mica. Calibro os tempos de recupera\u00e7\u00e3o: com que rapidez o PSI e o si\/so descem ap\u00f3s um pico? Se permanecerem elevados, isso \u00e9 um sinal de reservas insuficientes ou de uma estrat\u00e9gia de swap\/dirty inadequada. Assim, o planeamento de capacidade torna-se um processo cont\u00ednuo, em vez de uma estimativa anual.<\/p>\n\n<h2>Alerta e ajuste controlado por SLO<\/h2>\n<p>Associo o PSI aos SLOs dos utilizadores: se o \u201esome avg10\u201c aumentar em simult\u00e2neo com as lat\u00eancias da API, intervenho. Classifico os alertas em \u201eamarelo\u201c (permanente: 2\u20133 % \u201esome\u201c, \u201efull\u201c pr\u00f3ximo de 0) e \u201evermelho\u201c (mais de 5 % \u201esome\u201c ou \u201efull\u201c &gt; 0,1 %). Os alarmes baseados em cgroups ajudam a isolar a minoria ruidosa. Al\u00e9m disso, defino alarmes para o aumento das filas \u00abdirty\u00bb e dos tempos de espera de escrita, para que eu possa suavizar as ondas \u00abdirty\u00bb atempadamente. O objetivo \u00e9 que as medidas de ajuste (swappiness, memory.high, tamanhos de cache) sejam observ\u00e1veis e revers\u00edveis; implemento as altera\u00e7\u00f5es gradualmente e comparo o antes e o depois atrav\u00e9s das mesmas m\u00e9tricas.<\/p>\n\n<h2>Diagn\u00f3stico passo a passo no dia a dia<\/h2>\n\n<p>Primeiro, verifico o `free -h` e o `MemAvailable`: se o valor cair significativamente, procuro caches que possam ser devolvidos de forma \u00fatil e servi\u00e7os com hotsets em crescimento. Depois, executo o `vmstat` com intervalos curtos para identificar tend\u00eancias de si\/so; o swapping prolongado confirma a press\u00e3o e leva-me ao caminho de E\/S. Em seguida, leio o \/proc\/pressure\/memory e analiso os valores \u201esome\u201c e \u201efull\u201c ao longo de 10, 60 e 300 segundos; associo diretamente as m\u00e9dias crescentes \u00e0s lat\u00eancias observadas. O `dmesg` mostra-me vest\u00edgios de OOM e revela quais os processos que mais recentemente provocaram ou sofreram crises de mem\u00f3ria; a partir da\u00ed, deduzo limites e prioridades para os Cgroups. Com base em tudo isto, formulo uma hip\u00f3tese, implemento pequenos ajustes, verifico atrav\u00e9s do PSI e mantenho a <strong>Tempo de resposta<\/strong> num relance.<\/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\/08\/hosting-serverraum-4671.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Manuais de procedimentos e cadeias de causas t\u00edpicas<\/h2>\n<p>H\u00e1 alguns padr\u00f5es com os quais me deparo repetidamente:<\/p>\n<ul>\n  <li><strong>As tarefas de c\u00f3pia de seguran\u00e7a ou de digitaliza\u00e7\u00e3o substituem a cache de p\u00e1ginas<\/strong>: De repente, as taxas de acerto da cache baixam e a Web\/base de dados ficam mais lentas. Medida: reduzir a carga dos tarefas (prioridade de E\/S), deslocar o intervalo de tempo, definir \u00abmemory.high\u00bb para o cgroup das tarefas e proteger o or\u00e7amento da cache de p\u00e1ginas dos servi\u00e7os cr\u00edticos.<\/li>\n  <li><strong>Fugas nos processos \u00abworker\u00bb<\/strong>: Aumentos graduais da mem\u00f3ria an\u00f3nima; o PSI \u201esome\u201c continua a subir ao longo de v\u00e1rias horas. Medida: identificar a fuga de mem\u00f3ria, implementar pol\u00edticas de rein\u00edcio autom\u00e1tico e reciclagem, definir limites de mem\u00f3ria para que as fugas n\u00e3o ponham em risco todo o anfitri\u00e3o.<\/li>\n  <li><strong>Perda de sustenta\u00e7\u00e3o causada pelo THP<\/strong>: A carga do kcompactd aumenta durante os picos de tr\u00e1fego. Medida: Definir o THP para \u201emadvise\u201c, ajustar os servi\u00e7os afetados, verificar os par\u00e2metros de compacta\u00e7\u00e3o e aumentar a margem de seguran\u00e7a.<\/li>\n  <li><strong>Impress\u00e3o local NUMA<\/strong>: Um socket est\u00e1 sobrecarregado, apesar de haver RAM livre a n\u00edvel global. Medida: corrigir as afinidades, utilizar o interleave para cargas de trabalho amplamente distribu\u00eddas e ajustar a distribui\u00e7\u00e3o de carga no agendador.<\/li>\n  <li><strong>Swap em discos lentos<\/strong>: se o si\/so aumentar, os tempos de resposta disparam. Medida: transferir o swap para um armazenamento mais r\u00e1pido, avaliar o zswap\/zram, ajustar a swappiness e as pol\u00edticas do cgroup.<\/li>\n<\/ul>\n<p>Cada runbook termina com uma valida\u00e7\u00e3o: os valores \u201esome\/full\u201c aparecem e as lat\u00eancias estabilizam-se? Se n\u00e3o, a hip\u00f3tese estava errada ou incompleta \u2013 nesse caso, continuo a iterar.<\/p>\n\n<h2>Ferramentas e tra\u00e7ado em funcionamento<\/h2>\n<p>Para al\u00e9m das ferramentas cl\u00e1ssicas, aposto numa an\u00e1lise mais aprofundada: observo as rela\u00e7\u00f5es entre a cache de p\u00e1ginas e os dados an\u00f3nimos, as taxas de falhas de p\u00e1gina, os padr\u00f5es de refalha e as filas de writeback. As abordagens eBPF e de rastreamento indicam-me com precis\u00e3o onde surgem os tempos de espera \u2013 por exemplo, ao longo dos percursos de recupera\u00e7\u00e3o, no writeback ou na aloca\u00e7\u00e3o de blocos de grande dimens\u00e3o. Para mim, \u00e9 importante uma instrumenta\u00e7\u00e3o eficiente e adequada para produ\u00e7\u00e3o: janelas de ativa\u00e7\u00e3o curtas, amostragem em vez de monitoriza\u00e7\u00e3o cont\u00ednua e uma correla\u00e7\u00e3o clara com as m\u00e9tricas da aplica\u00e7\u00e3o. Assim, consigo identificar as causas antes de ajustar par\u00e2metros em grande escala.<\/p>\n\n<h2>Pontos-chave e pr\u00f3ximos passos<\/h2>\n\n<p>A \u00abMemory Pressure\u00bb descreve o tempo perdido devido \u00e0 escassez de mem\u00f3ria, e n\u00e3o apenas \u00e0 RAM ocupada; eu avalio-a com o PSI, identifico tend\u00eancias numa fase precoce e tomo medidas com base nos dados. Quem analisar em conjunto o MemAvailable, o vmstat si\/so, o PSI e o dmesg descobre as verdadeiras causas dos picos de lat\u00eancia e do thrashing. Atrav\u00e9s do ajuste dos par\u00e2metros Swappiness, Dirty e Cgroup, reduzo os bloqueios de forma direcionada e garanto que os servi\u00e7os importantes tenham o seu <strong>espa\u00e7o livre<\/strong>. Ao n\u00edvel da arquitetura, a distribui\u00e7\u00e3o horizontal, a defini\u00e7\u00e3o clara das fun\u00e7\u00f5es e os percursos r\u00e1pidos de armazenamento atenuam as consequ\u00eancias de qualquer pico de carga. No final, o que importa \u00e9 que eu relacione continuamente o diagn\u00f3stico com as medidas corretivas: medir, ajustar, medir novamente \u2013 at\u00e9 que o desempenho e <strong>Estabilidade<\/strong> voltar a servir.<\/p>","protected":false},"excerpt":{"rendered":"<p>Descubra como a press\u00e3o de mem\u00f3ria no kernel do Linux influencia o desempenho da hospedagem, como funcionam as m\u00e9tricas PSI e quais s\u00e3o as otimiza\u00e7\u00f5es necess\u00e1rias para a mem\u00f3ria do servidor.<\/p>","protected":false},"author":1,"featured_media":20205,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20212","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"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":"87","_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":"Memory Pressure","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":"20205","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20212","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=20212"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20212\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/20205"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=20212"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=20212"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=20212"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}