{"id":21199,"date":"2026-08-31T11:49:34","date_gmt":"2026-08-31T09:49:34","guid":{"rendered":"https:\/\/webhosting.de\/linux-cgroup-v2-memory-controller-erklaerung-hosting-resourcen-focus\/"},"modified":"2026-08-31T11:49:34","modified_gmt":"2026-08-31T09:49:34","slug":"explicacao-sobre-o-controlador-de-memoria-cgroup-v2-do-linux-foco-nos-recursos-de-alojamento","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/linux-cgroup-v2-memory-controller-erklaerung-hosting-resourcen-focus\/","title":{"rendered":"O controlador de mem\u00f3ria cgroup v2 do Linux explicado \u2013 Limitar recursos de forma eficaz"},"content":{"rendered":"<p>Eu explico como <strong>cgroup v2<\/strong> que, atrav\u00e9s do seu controlador de mem\u00f3ria, implementa limites de mem\u00f3ria de forma rigorosa, protege os servi\u00e7os e isola os eventos OOM locais. Desta forma, os administradores definem claramente <strong>Recursos<\/strong>- Estabelecem regras, regulam os picos de carga de forma controlada e protegem os processos cr\u00edticos contra a falta de energia armazenada.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<p>A lista que se segue resume os aspetos essenciais que abordo concretamente neste artigo.<\/p>\n<ul>\n  <li><strong>Normalizado<\/strong> Arquitetura: o cgroup v2 simplifica o controlo e a monitoriza\u00e7\u00e3o.<\/li>\n  <li><strong>Dif\u00edcil<\/strong> Limite: o `memory.max` impede aloca\u00e7\u00f5es descontroladas.<\/li>\n  <li><strong>Suave<\/strong> Trav\u00e3o: o \u00abmemory.high\u00bb reduz a press\u00e3o sem causar mortes imediatas.<\/li>\n  <li><strong>Mais espec\u00edfico<\/strong> Prote\u00e7\u00e3o: \u00abmemory.low\u00bb e \u00abmemory.min\u00bb d\u00e3o prioridade aos servi\u00e7os.<\/li>\n  <li><strong>Transparente<\/strong> Controlo: a vari\u00e1vel \u00abmemory.current\u00bb fornece valores de medi\u00e7\u00e3o para o ajuste.<\/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\/08\/serverraum-ressourcen-6912.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>O que o cgroup v2 faz de diferente em termos de mem\u00f3ria<\/h2>\n\n<p>Resumo os processos em <strong>Controlo<\/strong> Agrupo-os e controlo as suas necessidades de mem\u00f3ria como uma unidade. Com a vers\u00e3o v2, o kernel unifica as interfaces, o que me permite aplicar limites, limiares de prote\u00e7\u00e3o e telemetria de forma consistente. A l\u00f3gica de mem\u00f3ria separa a segrega\u00e7\u00e3o r\u00edgida dos trav\u00f5es suaves, o que n\u00e3o interrompe imediatamente as aloca\u00e7\u00f5es, mas sim as abranda de forma ordenada. Assim, consigo reagir a picos de atividade sem afetar o sistema global, uma vez que as interrup\u00e7\u00f5es ocorrem localmente no grupo afetado. Para alojamento e contentores, isto proporciona a previsibilidade <strong>Recursos<\/strong>-Distribui\u00e7\u00e3o e rea\u00e7\u00f5es previs\u00edveis a picos de carga.<\/p>\n\n<p>Utilizo estas caracter\u00edsticas para agrupar servi\u00e7os com perfis semelhantes e definir regras claras. Separo claramente os contentores, os workers PHP e os processos da base de dados, de modo a que cada conjunto de cargas de trabalho tenha os seus pr\u00f3prios limites. Desta forma, evito interfer\u00eancias, como a press\u00e3o global na mem\u00f3ria, que afeta tarefas inofensivas. Este isolamento pode ser aperfei\u00e7oado gradualmente, at\u00e9 que a distribui\u00e7\u00e3o da carga reaja de forma previs\u00edvel. Com isso, ganho <strong>Previsibilidade<\/strong> durante o funcionamento e mantenho a qualidade do servi\u00e7o sob picos de procura.<\/p>\n\n<h2>Vis\u00e3o geral dos ficheiros fiscais<\/h2>\n\n<p>A gest\u00e3o da mem\u00f3ria gira em torno de alguns poucos <strong>Par\u00e2metros<\/strong>, que defino no sistema de ficheiros do cgroup. Cada cgroup recebe os seus pr\u00f3prios valores para limites r\u00edgidos, pontos de travagem flex\u00edveis e linhas de prote\u00e7\u00e3o. Desta forma, consigo escalar desde uma recupera\u00e7\u00e3o moderada at\u00e9 a isolamento sem concess\u00f5es, dependendo da import\u00e2ncia do servi\u00e7o. O sistema de monitoriza\u00e7\u00e3o l\u00ea em paralelo a utiliza\u00e7\u00e3o atual e emite um alarme quando os limites de prote\u00e7\u00e3o s\u00e3o atingidos. Assim, cria-se um ciclo de controlo fechado entre valores predefinidos e valores medidos, que <strong>Recursos<\/strong>- permite controlar o consumo.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Par\u00e2metros<\/th>\n      <th>Tipo<\/th>\n      <th>Efeito<\/th>\n      <th>Utiliza\u00e7\u00e3o t\u00edpica<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>mem\u00f3ria.max<\/td>\n      <td>Dif\u00edcil <strong>Fronteira<\/strong><\/td>\n      <td>Bloqueia novas aloca\u00e7\u00f5es acima do limite; encerramento local por OOM<\/td>\n      <td>Bases de dados, JVMs, conjuntos de inst\u00e2ncias do PHP-FPM com limites bem definidos<\/td>\n    <\/tr>\n    <tr>\n      <td>mem\u00f3ria.alta<\/td>\n      <td>Suave <strong>trav\u00e3o<\/strong><\/td>\n      <td>Aumenta o Reclaim e a lat\u00eancia nas aloca\u00e7\u00f5es; n\u00e3o provoca mortes imediatas<\/td>\n      <td>Uma interven\u00e7\u00e3o suave antes da escalada<\/td>\n    <\/tr>\n    <tr>\n      <td>mem\u00f3ria.baixa<\/td>\n      <td>Suave<strong>Prote\u00e7\u00e3o<\/strong><\/td>\n      <td>A melhor prote\u00e7\u00e3o poss\u00edvel contra o \u00abreclama\u00e7\u00e3o\u00bb abaixo do limiar<\/td>\n      <td>Middleware importante, caches, servi\u00e7os centrais<\/td>\n    <\/tr>\n    <tr>\n      <td>mem\u00f3ria.min<\/td>\n      <td>Mais duro <strong>Prote\u00e7\u00e3o<\/strong><\/td>\n      <td>N\u00e3o h\u00e1 \u00abReclaim\u00bb abaixo do limiar; o OOM afeta mais outros grupos<\/td>\n      <td>Componentes essenciais cr\u00edticos<\/td>\n    <\/tr>\n    <tr>\n      <td>memory.current<\/td>\n      <td>Ao vivo-<strong>Valor<\/strong><\/td>\n      <td>Mostra a utiliza\u00e7\u00e3o atual; serve de base para alarmes e afina\u00e7\u00e3o<\/td>\n      <td>Pain\u00e9is de controlo, an\u00e1lises de tend\u00eancias<\/td>\n    <\/tr>\n    <tr>\n      <td>memory.oom.group<\/td>\n      <td>Kill-<strong>\u00c2mbito<\/strong><\/td>\n      <td>Agrupa as mortes OOM a n\u00edvel de grupo<\/td>\n      <td>Encerramento consistente de processos relacionados<\/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\/linuxcgroup-memory-2321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Compreender as hierarquias e a heran\u00e7a<\/h2>\n\n<p>Estou a organizar os cgroups <strong>hier\u00e1rquico<\/strong>: Os grupos de n\u00edvel superior definem o quadro, os filhos herdam limites e partilham a mem\u00f3ria dispon\u00edvel. Esta estrutura torna as restri\u00e7\u00f5es previs\u00edveis, mas exige regras claras. O valor de `memory.max` dos pais limita a soma dos filhos; os valores de `memory.low` e `memory.min` atuam, em caso de concorr\u00eancia ao n\u00edvel dos irm\u00e3os, como <strong>Prioridades<\/strong>: Um grupo com maior n\u00edvel de prote\u00e7\u00e3o tende a manter a sua mem\u00f3ria de base, enquanto os grupos menos importantes s\u00e3o alvo de uma recupera\u00e7\u00e3o mais intensa. Isso ajuda-me a garantir os percursos principais sem comprometer os limites m\u00e1ximos globais.<\/p>\n\n<p>Constato que os valores de prote\u00e7\u00e3o <strong>aditivo<\/strong> O que se pretende \u00e9 o seguinte: valores demasiado elevados para `memory.min` em todos os elementos filhos bloqueiam a recupera\u00e7\u00e3o de mem\u00f3ria na hierarquia e transferem a press\u00e3o para cima, at\u00e9 ao host. Por isso, calibro os limites de prote\u00e7\u00e3o por n\u00edvel e deixo sempre uma margem de seguran\u00e7a dispon\u00edvel. Em modelos por n\u00edveis, defino classes (cr\u00edtica, importante, best effort) e aplico larguras de banda e limiares de prote\u00e7\u00e3o consistentes para cada classe. Desta forma, a distribui\u00e7\u00e3o da carga permanece justa e transparente \u2014 mesmo quando as equipas gerem subgrupos de forma aut\u00f3noma.<\/p>\n\n<h2>Limite r\u00edgido: definir corretamente o `memory.max`<\/h2>\n\n<p>Eu fixo <strong>mem\u00f3ria.max<\/strong> de forma a que o processo tenha espa\u00e7o suficiente para picos, sem, no entanto, dominar o servidor. Para tal, me\u00e7o picos realistas, acrescento uma reserva e, em seguida, aplico um limite de forma consistente. Se um servi\u00e7o atingir esse limite superior, as aloca\u00e7\u00f5es s\u00e3o suspensas e o kernel encerra os processos locais dentro do grupo. Este isolamento evita efeitos em cadeia noutras cargas de trabalho. Para servi\u00e7os que consomem muita mem\u00f3ria, isto traz uma clara <strong>Seguran\u00e7a<\/strong> sem danos transversais.<\/p>\n\n<p>Para heaps ou caches de grande dimens\u00e3o, prevejo deliberadamente uma margem de seguran\u00e7a, pois a recolha de lixo e as tarefas em segundo plano provocam picos de carga. Valido o limite com testes de carga, para que n\u00e3o ocorram eventos OOM durante o funcionamento normal. Se a utiliza\u00e7\u00e3o se mantiver permanentemente pr\u00f3xima do limite, aumento primeiro a reserva ou reduzo a carga de trabalho propriamente dita. Desta forma, mantenho a margem de erro reduzida e a efici\u00eancia elevada. Esta disciplina compensa em <strong>Disponibilidade<\/strong> de.<\/p>\n\n<h2>Travagem suave: memory.high no dia-a-dia<\/h2>\n\n<p>Com <strong>mem\u00f3ria.alta<\/strong> defino um ponto de aviso e de travagem antes do limite cr\u00edtico. Se o grupo ultrapassar esse valor, o kernel ativa o Reclaim e abranda as aloca\u00e7\u00f5es, sem proceder imediatamente \u00e0 limpeza. Aproveito esse tempo para esvaziar as caches, escalonar a carga em lotes ou reduzir os limites de pedidos. Desta forma, suavizo os picos antes mesmo de ser necess\u00e1rio interromper processos. Isto melhora a <strong>Qualidade do servi\u00e7o<\/strong> em caso de picos de carga repentinos.<\/p>\n\n<p>Escolho uma diferen\u00e7a significativa entre memory.high e memory.max, para que o sistema tenha uma margem de manobra real. Se a diferen\u00e7a for demasiado pequena, chego demasiado depressa ao OOM. Se for demasiado grande, perco o controlo sobre as lat\u00eancias. Testo ambas as op\u00e7\u00f5es em perfis de produ\u00e7\u00e3o e calibro o ponto ideal. Desta forma, consigo criar uma <strong>Acelerador<\/strong>, que entre em vigor atempadamente.<\/p>\n\n<h2>Pol\u00edtica de swap: selecionar cuidadosamente o valor de memory.swap.max<\/h2>\n\n<p>Sou eu que decido se e em que medida um grupo <strong>Troca<\/strong> possa utilizar. Com o `memory.swap.max`, limito a troca de mem\u00f3ria separadamente do limite de RAM. Se definir o valor para 0, pro\u00edbo a troca de mem\u00f3ria para o grupo \u2013 o que faz sentido para servi\u00e7os sens\u00edveis \u00e0 lat\u00eancia que n\u00e3o podem bloquear. Se permitir uma utiliza\u00e7\u00e3o moderada da mem\u00f3ria de swap, ganho elasticidade para as caches e para as p\u00e1ginas raramente utilizadas. \u00c9 importante que eu <strong>urg\u00eancia<\/strong> conhe\u00e7a os tipos de cargas de trabalho: as bases de dados e as JVMs beneficiam frequentemente de uma pol\u00edtica de swap rigorosa ou muito restritiva, enquanto os trabalhos em lote ou de relat\u00f3rios lidam de forma mais flex\u00edvel com a mem\u00f3ria de swap.<\/p>\n\n<p>Estabele\u00e7o uma correla\u00e7\u00e3o entre a estrat\u00e9gia de swap e a configura\u00e7\u00e3o do host (por exemplo, swappiness, zram\/zswap), para que as medidas n\u00e3o se contradigam. O uso excessivo do swap apenas mascara a escassez de mem\u00f3ria a curto prazo e transfere a carga para as opera\u00e7\u00f5es de E\/S \u2014 utilizo-o de forma seletiva como <strong>Tamp\u00e3o<\/strong>, e n\u00e3o como uma situa\u00e7\u00e3o permanente. Os valores medidos, como as falhas de p\u00e1gina graves e as lat\u00eancias, revelam rapidamente se a troca de mem\u00f3ria ajuda ou prejudica o desempenho. \u00c9 assim que mantenho o controlo sobre os atrasos e as lat\u00eancias de cauda.<\/p>\n\n<h2>Linhas de prote\u00e7\u00e3o: memory.low e memory.min<\/h2>\n\n<p>Eu uso <strong>mem\u00f3ria.baixa<\/strong>, para garantir a mem\u00f3ria de base aos servi\u00e7os importantes. Enquanto a utiliza\u00e7\u00e3o se mantiver abaixo desse valor, o kernel poupa essa parte e prefere recuperar mem\u00f3ria noutros locais. Para componentes com prioridade elevada, utilizo adicionalmente o `memory.min`. Esta linha de prote\u00e7\u00e3o r\u00edgida deixa claro ao kernel que n\u00e3o permito qualquer recupera\u00e7\u00e3o nesta \u00e1rea. Assim, o n\u00facleo de uma aplica\u00e7\u00e3o permanece operacional mesmo sob carga extrema e <strong>reativo<\/strong>.<\/p>\n\n<p>Estabele\u00e7o esta pondera\u00e7\u00e3o de forma deliberada: as bases de dados centrais recebem \u00abmemory.min\u00bb, o middleware cr\u00edtico recebe \u00abmemory.low\u00bb e os trabalhos em lote n\u00e3o cr\u00edticos n\u00e3o recebem prote\u00e7\u00e3o adicional. Esta prioriza\u00e7\u00e3o facilita a tomada de decis\u00f5es em situa\u00e7\u00f5es de congestionamento. Se ocorrer um OOM, esta classifica\u00e7\u00e3o protege os meus caminhos-chave. Mantenho o controlo sobre quem cede mem\u00f3ria em primeiro lugar. Isso proporciona-me clareza <strong>Prioridades<\/strong> em caso de estrangulamentos.<\/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-control-explained-2984.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Transpar\u00eancia: memory.current na monitoriza\u00e7\u00e3o<\/h2>\n\n<p>Eu leio <strong>memory.current<\/strong> Analiso-o continuamente e correlaciono-o com as m\u00e9tricas da aplica\u00e7\u00e3o. Assim, consigo identificar tend\u00eancias, o ac\u00famulo de tarefas pendentes e picos de carga. Se o sistema registar um aumento nos casos de ultrapassagem do valor \u00abmemory.high\u00bb ou em eventos OOM, ajusto os limites ou a carga de trabalho. Os pain\u00e9is de controlo e os alarmes d\u00e3o-me uma vantagem na antecipa\u00e7\u00e3o de falhas. A partir destes dados, deduzo <strong>Afina\u00e7\u00e3o<\/strong>-toma decis\u00f5es que evitam perdas a longo prazo.<\/p>\n\n<p>Para al\u00e9m do pr\u00f3prio valor, observo as taxas de falhas de p\u00e1gina, a taxa de acertos na cache e as lat\u00eancias. Esta perspetiva permite verificar se o Reclaim est\u00e1 a causar um abrandamento excessivo ou se as linhas de prote\u00e7\u00e3o est\u00e3o a ser acionadas. Ajusto os intervalos e os valores-limite at\u00e9 que os alarmes sejam \u00fateis e n\u00e3o se tornem inc\u00f3modos. Depois, automatizo medidas corretivas, como o \u00abCache-Trim\u00bb ou a limita\u00e7\u00e3o da fila. Desta forma, a rea\u00e7\u00e3o continua a ser r\u00e1pida e <strong>direcionado<\/strong>.<\/p>\n\n<h2>Telemetria aprofundada: memory.stat, memory.events e PSI<\/h2>\n\n<p>Vou adicionar o seguinte ao `memory.current`: <strong>memory.stat<\/strong> e <strong>memory.events<\/strong>, para identificar as causas em vez de apenas os sintomas. O `memory.stat` divide a utiliza\u00e7\u00e3o em Anon, File-Cache, Slab e outras categorias. A partir destas percentagens, consigo determinar se as aloca\u00e7\u00f5es de uma aplica\u00e7\u00e3o ou do cache de p\u00e1ginas est\u00e3o a aumentar \u2013 e ajustar as configura\u00e7\u00f5es em conformidade (por exemplo, tamanhos do cache vs. n\u00famero de trabalhadores). memory.events e memory.events.local contabilizam eventos como exced\u00eancias dos limites low\/high\/max, bem como <strong>oom<\/strong> e <strong>oom_kill<\/strong>. Isto proporciona crit\u00e9rios fi\u00e1veis para os alarmes e a corre\u00e7\u00e3o autom\u00e1tica.<\/p>\n\n<p>Tamb\u00e9m utilizo <strong>PSI<\/strong> (Informa\u00e7\u00e3o sobre Estolagem por Press\u00e3o), para quantificar a press\u00e3o em vez de fazer suposi\u00e7\u00f5es. Se os valores de PSI da mem\u00f3ria aumentarem de forma sustentada, os threads sofrem tempos de espera; reduzo a carga de trabalho, aumento o valor de memory.high ou alivio a largura de banda no pipeline. No total, resulta numa telemetria que me permite uma avalia\u00e7\u00e3o gradual <strong>Alertas precoces<\/strong> oferece \u2013 antes que se imponham limites r\u00edgidos.<\/p>\n\n<h2>Contentores e orquestra\u00e7\u00e3o<\/h2>\n\n<p>Se eu definir limites de mem\u00f3ria no Kubernetes, estes ficam como <strong>cgroup<\/strong>Valores como `memory.max` e, opcionalmente, `memory.high` no ambiente de execu\u00e7\u00e3o. A orquestra\u00e7\u00e3o aplica pol\u00edticas por pod, enquanto eu defino os pormenores por namespace ou deployment. Para garantir SLOs fi\u00e1veis, associo limites a estrat\u00e9gias HPA e or\u00e7amentos de pod. Esta abordagem global impede que pods individuais monopolizem a mem\u00f3ria. Uma boa introdu\u00e7\u00e3o a <a href=\"https:\/\/webhosting.de\/pt\/cgroups-hosting-isolamento-de-recursos-linux-containerlimits-serverboost\/\">Isolamento de recursos com cgroups<\/a> facilita o planeamento de contentores com limites bem definidos e vias de acesso.<\/p>\n\n<p>Al\u00e9m disso, verifico se os sidecars e os init-containers t\u00eam os seus pr\u00f3prios limites, para que os processos auxiliares n\u00e3o limitem as cargas de trabalho principais. Para cargas de trabalho com estado, defino \u00abmemory.low\u00bb ou \u00abmemory.min\u00bb, para que as caches e os buffers n\u00e3o diminuam imediatamente. Documento estas decis\u00f5es na implementa\u00e7\u00e3o, para que a equipa as compreenda facilmente. Desta forma, garanto que <strong>Consist\u00eancia<\/strong> entre a infraestrutura e a aplica\u00e7\u00e3o. O resultado s\u00e3o perfis de carga de trabalho previs\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\/08\/Tech_Office_Linux_cgroup_7458.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Integra\u00e7\u00e3o com o Systemd e automatiza\u00e7\u00e3o<\/h2>\n\n<p>Utilizo o systemd para definir os par\u00e2metros do cgroup v2 de forma declarativa: <strong>Mem\u00f3riaMax<\/strong> corresponde a memory.max, <strong>Mem\u00f3riaAlta<\/strong> o memory.high, <strong>MemoryLow<\/strong> e <strong>MemoryMin<\/strong> estabelecem linhas de prote\u00e7\u00e3o, <strong>MemorySwapMax<\/strong> O Swap gere isso. Esta representa\u00e7\u00e3o torna as pol\u00edticas compreens\u00edveis no reposit\u00f3rio de c\u00f3digo e facilita as revers\u00f5es. Em ambientes de maior dimens\u00e3o, utilizo-a para orquestrar de forma consistente <strong>Normas<\/strong> por classe de servi\u00e7o e dissociar o funcionamento das interven\u00e7\u00f5es manuais.<\/p>\n\n<p>Para interven\u00e7\u00f5es autom\u00e1ticas, combino eventos do memory.events\/PSI com motores de pol\u00edticas. Se um grupo ultrapassar repetidamente o valor de `memory.high`, reduzo o n\u00famero de trabalhadores em paralelo, limito as taxas de pico ou aciono <strong>espec\u00edficos<\/strong> Cache-Trim. Se estas etapas n\u00e3o surtirem efeito, deixo que os mecanismos OOM nativos do sistema atuem de forma controlada \u2013 atrav\u00e9s do `memory.oom.group`, o efeito permanece local e previs\u00edvel. Desta forma, cria-se um comportamento gradual e de autocorre\u00e7\u00e3o, sem surpresas.<\/p>\n\n<h2>Alojamento multi-tenant com CloudLinux<\/h2>\n\n<p>Isolo os ambientes dos clientes em <strong>cgroups<\/strong> e atribuo limites claros a cada inquilino. O CloudLinux complementa isso com ferramentas que delimitam a RAM, a CPU e a E\/S por conta. Desta forma, os efeitos de vizinhan\u00e7a mant\u00eam-se control\u00e1veis e os casos isolados de consumo excessivo n\u00e3o afetam todas as contas. Quem quiser aprofundar o tema encontrar\u00e1 uma vis\u00e3o geral pr\u00e1tica sobre <a href=\"https:\/\/webhosting.de\/pt\/cgroup-v2-cloudlinux-alojamento-partilhado-estavel\/\">CloudLinux e cgroup v2<\/a> no contexto da hospedagem partilhada. Desta forma, mantenho condi\u00e7\u00f5es justas <strong>Recursos<\/strong>-Distribui\u00e7\u00e3o por v\u00e1rios clientes.<\/p>\n\n<p>Defino o valor de `memory.max` por cliente com base no perfil di\u00e1rio medido, atribuo um valor de `memory.low` \u00e0s caches e protejo os processos essenciais com `memory.min`. Em caso de viola\u00e7\u00e3o dos limites, os mecanismos de regula\u00e7\u00e3o reduzem primeiro a velocidade, em vez de bloquear abruptamente as contas. Se ocorrer um OOM, este afeta apenas o grupo em quest\u00e3o a n\u00edvel local. Desta forma, a plataforma continua dispon\u00edvel para os outros utilizadores. Esta abordagem refor\u00e7a <strong>Planeamento<\/strong> face aos picos de tr\u00e1fego.<\/p>\n\n<h2>Casos especiais: Cache de p\u00e1ginas, THP e p\u00e1ginas de grande dimens\u00e3o<\/h2>\n\n<p>Fa\u00e7o a distin\u00e7\u00e3o entre <strong>An\u00f3nimo<\/strong>-Mem\u00f3ria (heaps, stacks) e <strong>Cache de ficheiros<\/strong> (Cache de p\u00e1ginas). Em situa\u00e7\u00f5es de press\u00e3o, \u00e9 mais f\u00e1cil libertar o cache de ficheiros, enquanto as p\u00e1ginas an\u00f3nimas requerem swap ou levam a uma situa\u00e7\u00e3o de OOM. O `memory.high` e os limites de prote\u00e7\u00e3o ajudam-me a reduzir o cache de ficheiros sem afetar pilhas cr\u00edticas. No caso das Transparent Huge Pages (THP), verifico se estas beneficiam a aplica\u00e7\u00e3o ou se aumentam a fragmenta\u00e7\u00e3o e as lat\u00eancias \u2014 consoante o perfil, ajusto a pol\u00edtica de THP para que a intera\u00e7\u00e3o com o controlador de mem\u00f3ria se mantenha harmoniosa.<\/p>\n\n<p>Utiliza uma aplica\u00e7\u00e3o <strong>Hugepages<\/strong> Explicitamente, isolo as necessidades dessas reservas atrav\u00e9s dos controladores correspondentes, separadamente do controlo da RAM. Desta forma, evito que p\u00e1ginas de grande dimens\u00e3o ocupem a mem\u00f3ria de trabalho normal. Mantenho estas reservas especiais em n\u00edveis reduzidos e artico-as com os restantes limites, para que n\u00e3o surjam estrangulamentos inesperados. Em suma, criam-se diretrizes claras para o consumo de mem\u00f3ria regular e especial.<\/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_cgroup_me_script_1283.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Boas pr\u00e1ticas para limites<\/h2>\n\n<p>Come\u00e7o com perfis de consumo reais e defino <strong>mem\u00f3ria.max<\/strong> com margem de seguran\u00e7a, para que os picos n\u00e3o desencadeiem imediatamente o OOM. Defino o `memory.high` num valor visivelmente inferior, para suavizar os picos de carga e abrandar as aloca\u00e7\u00f5es. \u00c9 importante estabelecer prioridades: a base de dados recebe o `memory.min`, o middleware o `memory.low` e a carga em lote n\u00e3o tem um tratamento especial. A monitoriza\u00e7\u00e3o acompanha o funcionamento e indica se os limiares est\u00e3o a funcionar ou se foram definidos de forma demasiado rigorosa. Com base nestes sinais, ajusto os limites e, simultaneamente, aumento o <strong>Efici\u00eancia<\/strong> da aplica\u00e7\u00e3o.<\/p>\n\n<p>Registo os valores por servi\u00e7o, descrevo as justifica\u00e7\u00f5es e registo as altera\u00e7\u00f5es de forma compreens\u00edvel. Desta forma, consolido as decis\u00f5es na equipa e evito especula\u00e7\u00f5es semanas mais tarde. Antes de atualiza\u00e7\u00f5es ou mudan\u00e7as na arquitetura, analiso as curvas de evolu\u00e7\u00e3o para n\u00e3o tornar as regras mais rigorosas ou mais flex\u00edveis \u00e0s cegas. Uma pequena fase de testes poupa muitos problemas mais tarde na produ\u00e7\u00e3o. Este ritmo garante <strong>Constan\u00e7a<\/strong> na atividade quotidiana.<\/p>\n\n<h2>Pr\u00e1tica: Estruturar servidores de alojamento web<\/h2>\n\n<p>Crio uma conta espec\u00edfica para cada cliente <strong>cgroup<\/strong> e transfiro o PHP-FPM, a base de dados e a cache para l\u00e1. Atribuo a cada conjunto o valor de `memory.max` mais um buffer, enquanto o `memory.high` entra em a\u00e7\u00e3o mais cedo e suaviza os picos. Os servi\u00e7os cr\u00edticos do cliente recebem limites de prote\u00e7\u00e3o para que a sua mem\u00f3ria principal n\u00e3o caia. Os registos e os pain\u00e9is de controlo mostram quem est\u00e1 a travar, quem est\u00e1 a acelerar e onde existe risco de OOM. Al\u00e9m disso, as indica\u00e7\u00f5es sobre <a href=\"https:\/\/webhosting.de\/pt\/contexto-do-servidor-isolamento-namespaces-cgroups-alojamento-seguranca\/\">Espa\u00e7os de nomes e conceitos de isolamento<\/a>, para que os clientes permane\u00e7am claramente separados e <strong>Seguran\u00e7a<\/strong> aumenta.<\/p>\n\n<p>Al\u00e9m disso, ajusto o n\u00famero de workers PHP, os tamanhos do OPcache e das caches de consultas para reduzir a pegada de mem\u00f3ria. Muitas vezes, basta reduzir os picos atrav\u00e9s da vari\u00e1vel `memory.high` para diminuir o tempo de resposta. Para os testes, utilizo padr\u00f5es de carga reais, e n\u00e3o valores ideais sint\u00e9ticos. Posteriormente, documento os novos limites e associo-os aos SLAs. Assim, a <strong>Transpar\u00eancia<\/strong> perante os clientes e o apoio interno.<\/p>\n\n<h2>Resolu\u00e7\u00e3o de problemas na impress\u00e3o com mem\u00f3ria<\/h2>\n\n<p>Aumenta <strong>memory.current<\/strong> Rapidamente, verifico primeiro se houve altera\u00e7\u00f5es no tr\u00e1fego, nas implementa\u00e7\u00f5es ou nas configura\u00e7\u00f5es. Comparo as curvas dos picos de exced\u00eancia, das falhas de p\u00e1gina e das lat\u00eancias. Se ocorrerem OOMs em s\u00e9rie, identifico os processos afetados atrav\u00e9s do registo do kernel e ajusto os limites ou a carga de trabalho. Se a causa residir em caches defeituosas, fa\u00e7o um ajuste espec\u00edfico, em vez de resolver o problema de forma global. Esta cadeia de diagn\u00f3stico leva-me rapidamente \u00e0 <strong>Causa<\/strong>, e n\u00e3o apenas ao sintoma.<\/p>\n\n<p>Se a carga continuar elevada, distribuo o trabalho: defino limites de picos para o Ingress, reduzo o comprimento das filas e adio as tarefas em lote. Paralelamente, aumentei temporariamente o valor de `memory.high` para ganhar tempo de resposta, sem aumentar o `memory.max`. Se forem detetados fugas de mem\u00f3ria, estreito os limites de seguran\u00e7a at\u00e9 que haja uma corre\u00e7\u00e3o. Em casos persistentes, reduzo o \u00e2mbito do servi\u00e7o ou replico a inst\u00e2ncia. \u00c9 assim que mantenho o <strong>Funcionamento<\/strong> funciona de forma fi\u00e1vel, mesmo sob press\u00e3o.<\/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-cgroup-memory-4297.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Automa\u00e7\u00e3o: Medidas corretivas acionadas por eventos<\/h2>\n\n<p>Estou a fazer um n\u00f3 <strong>Ac\u00e7\u00f5es<\/strong> relativos a eventos: o `memory.events` fornece contadores que eu processei atrav\u00e9s de um Watcher ou de um pipeline de m\u00e9tricas. Em caso de \u00abhigh-hits\u00bb repetidos, esvazio caches de forma seletiva, reduzo a concorr\u00eancia ou inicio tentativas de recupera\u00e7\u00e3o antes que os utilizadores se apercebam de algo. Se as interven\u00e7\u00f5es moderadas falharem, recorro a medidas dr\u00e1sticas: suspens\u00e3o de pedidos, esvaziamento da fila, altera\u00e7\u00e3o de prioridades. O importante \u00e9 que as decis\u00f5es <strong>determin\u00edstico<\/strong> s\u00e3o \u2013 os mesmos est\u00edmulos, a mesma rea\u00e7\u00e3o \u2013, para que as equipas possam compreender e reproduzir esse comportamento.<\/p>\n\n<p>Al\u00e9m disso, vou ficar com a <strong>\u00c2mbito<\/strong> de olho no OOM. Com o `memory.oom.group`, evito encerramentos parciais que colocam as aplica\u00e7\u00f5es em estados inconsistentes. Se for necess\u00e1rio encerrar algo, que seja de forma coordenada e r\u00e1pida, para que as capacidades restantes fiquem rapidamente dispon\u00edveis novamente. Em combina\u00e7\u00e3o com telemetria e manuais de procedimentos documentados, cria-se um ciclo de feedback robusto que funciona em condi\u00e7\u00f5es reais de produ\u00e7\u00e3o.<\/p>\n\n<h2>Perspectivas e resumo<\/h2>\n\n<p>O controlador de mem\u00f3ria da <strong>cgroup<\/strong> A v2 oferece-me um conjunto de ferramentas graduadas: limites r\u00edgidos, trav\u00f5es suaves e linhas de prote\u00e7\u00e3o com prioridades claras. Ao utilizar de forma consciente os par\u00e2metros memory.max, memory.high, memory.low e memory.min, reajo de forma ordenada a picos de carga e mantenho os servi\u00e7os operacionais. A monitoriza\u00e7\u00e3o atrav\u00e9s de `memory.current` revela atempadamente onde os limites est\u00e3o a ser ultrapassados ou onde faltam reservas. Em configura\u00e7\u00f5es de contentores e multi-tenant, estes mecanismos garantem uma atribui\u00e7\u00e3o justa de recursos sem danos colaterais. Com disciplina, valores de medi\u00e7\u00e3o e pequenos passos de corre\u00e7\u00e3o, consigo obter resultados fi\u00e1veis <strong>Desempenho<\/strong> \u2013 desde a m\u00e1quina virtual individual at\u00e9 ao anfitri\u00e3o com elevada carga.<\/p>","protected":false},"excerpt":{"rendered":"<p>Descubra como funciona o controlador de mem\u00f3ria cgroup v2 do Linux e como pode criar ambientes de alojamento e de contentores est\u00e1veis atrav\u00e9s de limites de recursos espec\u00edficos do Linux.<\/p>","protected":false},"author":1,"featured_media":21192,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21199","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":"222","_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":"cgroup v2","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":"21192","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21199","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=21199"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21199\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21192"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21199"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21199"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21199"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}