{"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":"explicacion-del-controlador-de-memoria-cgroup-v2-de-linux-enfoque-en-los-recursos-de-alojamiento","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/linux-cgroup-v2-memory-controller-erklaerung-hosting-resourcen-focus\/","title":{"rendered":"Explicaci\u00f3n del controlador de memoria cgroup v2 de Linux: c\u00f3mo limitar los recursos de forma precisa"},"content":{"rendered":"<p>Explico c\u00f3mo <strong>cgroup v2<\/strong> que, gracias a su controlador de memoria, aplica correctamente los l\u00edmites de memoria, protege los servicios y a\u00edsla los incidentes locales de OOM. De este modo, los administradores establecen claramente <strong>Recursos<\/strong>-Establecen reglas, regulan los picos de carga de forma controlada y protegen los procesos cr\u00edticos frente a la falta de almacenamiento.<\/p>\n\n<h2>Puntos centrales<\/h2>\n<p>La siguiente lista resume los aspectos fundamentales que desarrollo en detalle en el art\u00edculo.<\/p>\n<ul>\n  <li><strong>Normalizado<\/strong> Arquitectura: cgroup v2 simplifica el control y la supervisi\u00f3n.<\/li>\n  <li><strong>Duro<\/strong> L\u00edmite: memory.max evita las asignaciones incontroladas.<\/li>\n  <li><strong>Suave<\/strong> Freno: \u00abmemory.high\u00bb reduce la presi\u00f3n sin provocar muertes inmediatas.<\/li>\n  <li><strong>M\u00e1s espec\u00edfico<\/strong> Protecci\u00f3n: \u00abmemory.low\u00bb y \u00abmemory.min\u00bb dan prioridad a los servicios.<\/li>\n  <li><strong>Transparente<\/strong> Control: memory.current proporciona valores de medici\u00f3n para el 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>En qu\u00e9 se diferencia cgroup v2 en cuanto a la memoria<\/h2>\n\n<p>Resumo los procesos en <strong>Controlar<\/strong> Agrupo los grupos y gestiono sus necesidades de memoria como una unidad. Con la versi\u00f3n v2, el n\u00facleo unifica las interfaces, lo que me permite aplicar de forma coherente los l\u00edmites, los umbrales de protecci\u00f3n y la telemetr\u00eda. La l\u00f3gica de memoria separa el aislamiento estricto de las restricciones suaves, lo que no bloquea las asignaciones de forma inmediata, sino que las ralentiza de manera ordenada. De este modo, puedo reaccionar ante valores at\u00edpicos sin que el sistema en su conjunto se vea afectado, ya que las interrupciones se producen localmente en el grupo en cuesti\u00f3n. Para el alojamiento y los contenedores, esto aporta la previsibilidad <strong>Recursos<\/strong>-Distribuci\u00f3n y reacciones previsibles ante picos de carga.<\/p>\n\n<p>Aprovecho estas caracter\u00edsticas para agrupar servicios con un perfil similar y establecer reglas claras. Separo claramente los contenedores, los trabajadores PHP y los procesos de la base de datos, de modo que cada conjunto de cargas de trabajo tenga sus propios l\u00edmites. De este modo, evito interferencias como la presi\u00f3n global sobre la memoria, que afecta a tareas inofensivas. Este aislamiento se puede ir perfeccionando gradualmente hasta que la distribuci\u00f3n de la carga reaccione de forma predecible. Con ello consigo <strong>Previsibilidad<\/strong> durante el funcionamiento y mantengo la calidad del servicio incluso en momentos de m\u00e1xima demanda.<\/p>\n\n<h2>Resumen de los archivos fiscales<\/h2>\n\n<p>La gesti\u00f3n de la memoria gira en torno a unos pocos <strong>Par\u00e1metros<\/strong>, que configuro en el sistema de archivos de cgroup. Cada cgroup recibe sus propios valores para l\u00edmites estrictos, puntos de frenado flexibles y l\u00edneas de protecci\u00f3n. De este modo, puedo ajustar el nivel de control, desde una recuperaci\u00f3n moderada hasta un aislamiento sin concesiones, en funci\u00f3n de la importancia del servicio. El sistema de monitorizaci\u00f3n lee en paralelo el uso actual y emite una alarma cuando se activan los umbrales de protecci\u00f3n. De este modo se crea un circuito de regulaci\u00f3n cerrado formado por valores predefinidos y valores medidos, que <strong>Recursos<\/strong>-permite controlar el consumo.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Par\u00e1metros<\/th>\n      <th>Atentamente<\/th>\n      <th>Efecto<\/th>\n      <th>Uso t\u00edpico<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>memoria.max<\/td>\n      <td>Duro <strong>Frontera<\/strong><\/td>\n      <td>Bloquea nuevas asignaciones por encima del l\u00edmite; cierre local por falta de memoria (OOM)<\/td>\n      <td>Bases de datos, JVM, grupos de PHP-FPM con l\u00edmites m\u00e1ximos claramente definidos<\/td>\n    <\/tr>\n    <tr>\n      <td>memoria.alta<\/td>\n      <td>Suave <strong>freno<\/strong><\/td>\n      <td>Aumenta el \u00abReclaim\u00bb y la latencia en las asignaciones; no se producen muertes inmediatas.<\/td>\n      <td>Una moderaci\u00f3n gradual antes de que la situaci\u00f3n se agrave<\/td>\n    <\/tr>\n    <tr>\n      <td>memoria.baja<\/td>\n      <td>Suave<strong>Protecci\u00f3n<\/strong><\/td>\n      <td>La mejor protecci\u00f3n posible contra el \u00abreclaim\u00bb por debajo del umbral<\/td>\n      <td>Middleware importante, cach\u00e9s, servicios centrales<\/td>\n    <\/tr>\n    <tr>\n      <td>memoria.min<\/td>\n      <td>M\u00e1s duro <strong>Protecci\u00f3n<\/strong><\/td>\n      <td>No hay \u00abReclaim\u00bb por debajo del umbral; el OOM afecta m\u00e1s bien a otros grupos<\/td>\n      <td>Componentes cr\u00edticos fundamentales<\/td>\n    <\/tr>\n    <tr>\n      <td>memory.current<\/td>\n      <td>En directo-<strong>Valor<\/strong><\/td>\n      <td>Muestra el consumo actual; sirve de base para las alarmas y el ajuste<\/td>\n      <td>Cuadros de mando, an\u00e1lisis de tendencias<\/td>\n    <\/tr>\n    <tr>\n      <td>memory.oom.group<\/td>\n      <td>Kill-<strong>\u00c1mbito<\/strong><\/td>\n      <td>Agrupa las muertes de OOM a nivel de grupo<\/td>\n      <td>Finalizaci\u00f3n coherente de los procesos 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>Comprender las jerarqu\u00edas y la herencia<\/h2>\n\n<p>Organizo los cgroups <strong>jer\u00e1rquico<\/strong>: Los grupos superiores establecen el marco; los hijos heredan los l\u00edmites y comparten la memoria disponible. Esta estructura hace que las especificaciones sean predecibles, pero exige reglas claras. El valor de `memory.max` de los padres limita la suma de los hijos; `memory.low` y `memory.min` act\u00faan, en caso de competencia entre hermanos, como <strong>Prioridades<\/strong>: Un grupo con mayor protecci\u00f3n tiende a conservar mejor su memoria de base, mientras que los grupos menos importantes se recuperan en mayor medida. Esto me ayuda a proteger las rutas principales sin rebajar los l\u00edmites m\u00e1ximos globales.<\/p>\n\n<p>Observo que los valores de protecci\u00f3n <strong>aditivo<\/strong> La idea es la siguiente: unas cantidades demasiado elevadas para \u00abmemory.min\u00bb en todos los elementos secundarios bloquean la recuperaci\u00f3n de recursos en la jerarqu\u00eda y trasladan la presi\u00f3n hacia arriba, hasta llegar al host. Por eso calibro los presupuestos de protecci\u00f3n por nivel y siempre dejo un margen libre. En los modelos por niveles, defino clases (cr\u00edtica, importante, mejor esfuerzo) y aplico anchos de banda y umbrales de protecci\u00f3n coherentes para cada clase. De este modo, la distribuci\u00f3n de la carga sigue siendo justa y transparente, incluso cuando los equipos gestionan subgrupos de forma aut\u00f3noma.<\/p>\n\n<h2>L\u00edmite estricto: configurar correctamente memory.max<\/h2>\n\n<p>He puesto <strong>memoria.max<\/strong> de tal forma que el proceso disponga de espacio suficiente para los picos, pero sin que acabe dominando el servidor. Para ello, mido los picos reales, a\u00f1ado una reserva y, a continuaci\u00f3n, aplico un l\u00edmite de forma sistem\u00e1tica. Si un servicio alcanza este l\u00edmite m\u00e1ximo, no se producen asignaciones y el n\u00facleo termina los procesos locales dentro del grupo. Esta encapsulaci\u00f3n evita efectos domin\u00f3 en otras cargas de trabajo. Para los servicios que consumen mucha memoria, esto supone una clara <strong>Seguridad<\/strong> sin da\u00f1os transversales.<\/p>\n\n<p>Para los montones o cach\u00e9s de gran tama\u00f1o, preveo deliberadamente un margen de seguridad, ya que la recolecci\u00f3n de basura y las tareas en segundo plano provocan picos de carga. Valido el l\u00edmite mediante pruebas de carga para evitar que se produzcan eventos de memoria insuficiente (OOM) durante el funcionamiento normal. Si el uso se mantiene constantemente cerca del l\u00edmite, primero aumento la reserva o reduzco la carga de trabajo real. De este modo, mantengo el margen de error reducido y la eficiencia alta. Esta disciplina da sus frutos en <strong>Disponibilidad<\/strong> de.<\/p>\n\n<h2>Freno suave: memory.high en el d\u00eda a d\u00eda<\/h2>\n\n<p>Con <strong>memoria.alta<\/strong> Establezco un punto de aviso y de frenada antes de llegar al l\u00edmite. Si el grupo supera ese valor, el kernel activa Reclaim y ralentiza las asignaciones, sin proceder a la limpieza inmediata. Aprovecho ese tiempo para vaciar las cach\u00e9s, escalonar la carga por lotes o reducir los l\u00edmites de solicitudes. De este modo, suavizo los picos antes incluso de que sea necesario interrumpir procesos. Esto mejora la <strong>Calidad del servicio<\/strong> en caso de picos de carga repentinos.<\/p>\n\n<p>Elijo una diferencia notable entre memory.high y memory.max para que el sistema tenga un margen real. Si la diferencia es demasiado peque\u00f1a, acabo antes de tiempo con un error OOM. Si es demasiado grande, pierdo el control sobre las latencias. Pruebo ambas opciones en perfiles de producci\u00f3n y calibro el punto \u00f3ptimo. De este modo, consigo una <strong>Acelerador<\/strong>, que surta efecto a tiempo.<\/p>\n\n<h2>Pol\u00edtica de swap: seleccionar deliberadamente el valor de `memory.swap.max`<\/h2>\n\n<p>Yo decido si un grupo... y en qu\u00e9 medida... <strong>Intercambiar<\/strong> puedo utilizar. Con memory.swap.max limito el intercambio de memoria por separado del l\u00edmite de RAM. Si establezco el valor en 0, desactivo el intercambio de memoria para el grupo, lo cual es \u00fatil para servicios sensibles a la latencia que no deben bloquearse. Si permito un intercambio moderado, gano elasticidad para las cach\u00e9s y las p\u00e1ginas que se utilizan con poca frecuencia. Es importante que la <strong>urgencia<\/strong> conocer las cargas de trabajo: las bases de datos y las JVM suelen beneficiarse de una pol\u00edtica de intercambio m\u00e1s estricta o muy limitada, mientras que los trabajos por lotes o de generaci\u00f3n de informes gestionan el intercambio de forma m\u00e1s flexible.<\/p>\n\n<p>Correlaciono la estrategia de swap con la configuraci\u00f3n del host (por ejemplo, swappiness, zram\/zswap) para que las medidas no se contradigan entre s\u00ed. Un uso excesivo del swap solo enmascara la escasez de memoria a corto plazo y traslada la carga a las operaciones de E\/S; yo lo utilizo de forma selectiva como <strong>Tamp\u00f3n<\/strong>, no como una situaci\u00f3n permanente. Los valores medidos, como los \u00abMajor Page Faults\u00bb y las latencias, revelan r\u00e1pidamente si el swap ayuda o frena el sistema. As\u00ed mantengo el control sobre los retrasos y las latencias de cola.<\/p>\n\n<h2>L\u00edneas de protecci\u00f3n: memory.low y memory.min<\/h2>\n\n<p>Utilizo <strong>memoria.baja<\/strong>, para garantizar que los servicios importantes dispongan de memoria base. Mientras el uso se mantenga por debajo de ese nivel, el n\u00facleo respeta esa parte y prefiere recuperar memoria en otros lugares. Para los componentes de alta prioridad, utilizo adem\u00e1s memory.min. Esta l\u00ednea de protecci\u00f3n estricta deja claro al n\u00facleo que no permito la recuperaci\u00f3n de memoria en este caso. De este modo, el n\u00facleo de una aplicaci\u00f3n sigue siendo operativo incluso bajo una carga extrema y <strong>receptivo<\/strong>.<\/p>\n\n<p>Establezco la ponderaci\u00f3n de forma deliberada: las bases de datos centrales reciben \u00abmemory.min\u00bb, el middleware cr\u00edtico \u00abmemory.low\u00bb y los trabajos por lotes no cr\u00edticos no tienen protecci\u00f3n adicional. Esta priorizaci\u00f3n facilita la toma de decisiones en caso de cuellos de botella. Si se produce un error OOM, esta clasificaci\u00f3n protege mis rutas clave. Mantengo el control sobre qui\u00e9n cede memoria en primer lugar. Esto me aporta una clara <strong>Prioridades<\/strong> en caso de atascos.<\/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>Transparencia: \u00abmemory.current\u00bb en la supervisi\u00f3n<\/h2>\n\n<p>Leo <strong>memory.current<\/strong> lo analizo continuamente y lo correlaciono con las m\u00e9tricas de las aplicaciones. As\u00ed detecto tendencias, la acumulaci\u00f3n de trabajo pendiente y los picos. Si el sistema registra un aumento de los casos en los que se supera el valor de `memory.high` o de los eventos OOM, ajusto los l\u00edmites o la carga de trabajo. Los paneles de control y las alertas me permiten anticiparme a las incidencias. A partir de estos datos, deduzco <strong>Sintonizaci\u00f3n<\/strong>-toma decisiones que evitan las bajas a largo plazo.<\/p>\n\n<p>Adem\u00e1s del valor en s\u00ed, observo las tasas de fallos de p\u00e1gina, la tasa de aciertos de cach\u00e9 y las latencias. Esta perspectiva permite ver si \u00abReclaim\u00bb ralentiza demasiado el sistema o si se activan las l\u00edneas de protecci\u00f3n. Ajusto los intervalos y los umbrales hasta que las alarmas resulten \u00fatiles y no molestas. A continuaci\u00f3n, automatizo las medidas correctivas, como el \u00abcache trim\u00bb o la limitaci\u00f3n de colas. De este modo, la reacci\u00f3n sigue siendo r\u00e1pida y <strong>objetivo<\/strong>.<\/p>\n\n<h2>Telemetr\u00eda en profundidad: memory.stat, memory.events y PSI<\/h2>\n\n<p>A\u00f1ado lo siguiente a `memory.current`: <strong>memory.stat<\/strong> y <strong>memory.events<\/strong>, para identificar las causas en lugar de limitarme a los s\u00edntomas. memory.stat desglosa el uso en Anon, cach\u00e9 de archivos, slab y otras categor\u00edas. A partir de estos porcentajes, determino si est\u00e1n aumentando las asignaciones de una aplicaci\u00f3n o la cach\u00e9 de p\u00e1ginas, y realizo los ajustes necesarios (por ejemplo, tama\u00f1o de la cach\u00e9 frente al n\u00famero de trabajadores). memory.events y memory.events.local contabilizan eventos como los rebasamientos de los valores low\/high\/max, as\u00ed como <strong>oom<\/strong> y <strong>oom_kill<\/strong>. Esto proporciona criterios fiables para las alertas y la correcci\u00f3n autom\u00e1tica.<\/p>\n\n<p>Tambi\u00e9n utilizo <strong>PSI<\/strong> (Informaci\u00f3n sobre el estancamiento por presi\u00f3n), para cuantificar la presi\u00f3n en lugar de hacer conjeturas. Si los valores de Memory-PSI aumentan de forma permanente, los subprocesos sufren tiempos de espera en las p\u00e1ginas; reduzco la carga de trabajo, aumento el valor de memory.high o libero ancho de banda en la canalizaci\u00f3n. En resumen, se genera una telemetr\u00eda que me proporciona informaci\u00f3n gradual <strong>Alertas tempranas<\/strong> ofrece, antes de que se impongan l\u00edmites estrictos.<\/p>\n\n<h2>Contenedores y orquestaci\u00f3n<\/h2>\n\n<p>Si establezco l\u00edmites de memoria en Kubernetes, estos se almacenan como <strong>cgroup<\/strong>Valores como `memory.max` y, opcionalmente, `memory.high` en el entorno de ejecuci\u00f3n. La orquestaci\u00f3n aplica pol\u00edticas por pod, mientras que yo defino los detalles por espacio de nombres o despliegue. Para garantizar unos SLO fiables, vinculo los l\u00edmites con estrategias de HPA y presupuestos de pod. Este enfoque global evita que unos pocos pods acaparen la memoria. Una buena introducci\u00f3n a <a href=\"https:\/\/webhosting.de\/es\/cgroups-alojamiento-aislamiento-de-recursos-linux-containerlimits-serverboost\/\">Aislamiento de recursos con cgroups<\/a> Facilita la planificaci\u00f3n de contenedores con l\u00edmites bien definidos y zonas de acceso.<\/p>\n\n<p>Adem\u00e1s, compruebo si los sidecars y los contenedores de inicio tienen sus propios l\u00edmites, para que los procesos auxiliares no limiten las cargas de trabajo principales. Para las cargas de trabajo con estado, configuro \u00abmemory.low\u00bb o \u00abmemory.min\u00bb, para que las cach\u00e9s y los b\u00faferes no se reduzcan de inmediato. Documento estas decisiones en la implementaci\u00f3n para que el equipo las entienda f\u00e1cilmente. De esta forma, me aseguro de que <strong>Coherencia<\/strong> entre la infraestructura y la aplicaci\u00f3n. El resultado son perfiles de carga de trabajo predecibles.<\/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>Integraci\u00f3n con Systemd y automatizaci\u00f3n<\/h2>\n\n<p>Utilizo systemd para configurar de forma declarativa los par\u00e1metros de cgroup v2: <strong>MemoryMax<\/strong> equivale a memory.max, <strong>MemoriaAlta<\/strong> el memory.high, <strong>MemoryLow<\/strong> y <strong>MemoryMin<\/strong> establecen l\u00edneas de protecci\u00f3n, <strong>MemorySwapMax<\/strong> Lo gestiona Swap. Esta representaci\u00f3n permite hacer un seguimiento de las pol\u00edticas en el repositorio de c\u00f3digo y facilita la reversi\u00f3n de cambios. En entornos m\u00e1s grandes, lo utilizo para coordinar de forma coherente <strong>Normas<\/strong> por clase de servicio y desacoplar el funcionamiento de las intervenciones manuales.<\/p>\n\n<p>Para las intervenciones autom\u00e1ticas, combino eventos de memory.events\/PSI con motores de pol\u00edticas. Si un grupo supera repetidamente el valor de `memory.high`, reduzco el n\u00famero de trabajadores en paralelo, limito las tasas de picos o activo <strong>espec\u00edficas<\/strong> Cache-Trim. Si estas medidas no surten efecto, dejo que los mecanismos OOM propios del sistema act\u00faen de forma controlada: gracias a memory.oom.group, el efecto se mantiene local y predecible. De este modo se consigue un comportamiento gradual y autorreparador sin sorpresas.<\/p>\n\n<h2>Alojamiento multitenant con CloudLinux<\/h2>\n\n<p>Aislo los entornos de los clientes en <strong>cgroups<\/strong> y establezco l\u00edmites claros para cada inquilino. CloudLinux lo complementa con herramientas que delimitan la RAM, la CPU y las E\/S por cada cuenta. De este modo, los efectos de vecindad se mantienen bajo control y los casos aislados no afectan al resto de cuentas. Quien quiera profundizar m\u00e1s, encontrar\u00e1 una descripci\u00f3n pr\u00e1ctica sobre <a href=\"https:\/\/webhosting.de\/es\/cgroup-v2-cloudlinux-alojamiento-compartido-estable\/\">CloudLinux y cgroup v2<\/a> en el contexto del alojamiento compartido. De este modo, mantengo unas tarifas justas <strong>Recursos<\/strong>-Distribuci\u00f3n entre numerosos clientes.<\/p>\n\n<p>Establezco el valor de `memory.max` por cliente seg\u00fan el perfil diario medido, asigno un valor de `memory.low` a las cach\u00e9s y protejo los procesos cr\u00edticos con `memory.min`. En caso de que se superen los l\u00edmites, primero se aplican restricciones de rendimiento en lugar de bloquear las cuentas de forma dr\u00e1stica. Si se produce un error OOM, este afecta localmente al grupo en cuesti\u00f3n. De este modo, la plataforma sigue estando disponible para el resto de clientes. Este enfoque refuerza <strong>Planificabilidad<\/strong> frente a los picos de tr\u00e1fico.<\/p>\n\n<h2>Casos especiales: cach\u00e9 de p\u00e1ginas, THP y p\u00e1ginas de gran tama\u00f1o<\/h2>\n\n<p>Diferencio entre <strong>An\u00f3nimo<\/strong>-Memoria (heaps, stacks) y <strong>Cach\u00e9 de archivos<\/strong> (Cach\u00e9 de p\u00e1ginas). En situaciones de carga elevada, es m\u00e1s f\u00e1cil liberar la cach\u00e9 de archivos, mientras que las p\u00e1ginas an\u00f3nimas requieren espacio en el disco de intercambio o provocan un error de falta de memoria (OOM). Los par\u00e1metros `memory.high` y las l\u00edneas de protecci\u00f3n me ayudan a recuperar la cach\u00e9 de archivos sin afectar a los montones cr\u00edticos. En el caso de las p\u00e1ginas enormes transparentes (THP), compruebo si benefician a la aplicaci\u00f3n o si aumentan la fragmentaci\u00f3n y las latencias; en funci\u00f3n del perfil, ajusto la pol\u00edtica de THP para que la interacci\u00f3n con el controlador de memoria siga siendo coherente.<\/p>\n\n<p>Utiliza una aplicaci\u00f3n <strong>Hugepages<\/strong> De forma expl\u00edcita, a\u00edslo sus necesidades mediante los controladores correspondientes, separ\u00e1ndolas del control de la RAM. De este modo, evito que las p\u00e1ginas de gran tama\u00f1o desplacen a la memoria de trabajo habitual. Mantengo estas reservas especiales en niveles reducidos y las coordino con el resto de l\u00edmites para que no se produzcan cuellos de botella inesperados. En resumen, se establecen unas pautas claras para el consumo de memoria normal y 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>Buenas pr\u00e1cticas para los l\u00edmites<\/h2>\n\n<p>Empiezo con perfiles de consumo reales y establezco <strong>memoria.max<\/strong> con un margen, para que los picos no activen inmediatamente el OOM. Establezco \u00abmemory.high\u00bb notablemente por debajo, para suavizar los picos de carga y ralentizar las asignaciones. Es importante establecer prioridades: la base de datos recibe \u00abmemory.min\u00bb, el middleware \u00abmemory.low\u00bb y la carga por lotes no tiene un papel especial. La supervisi\u00f3n acompa\u00f1a el funcionamiento y muestra si los umbrales son eficaces o si se han seleccionado de forma demasiado estricta. En funci\u00f3n de estas se\u00f1ales, ajusto los l\u00edmites y, al mismo tiempo, aumento la <strong>Eficacia<\/strong> de la aplicaci\u00f3n.<\/p>\n\n<p>Documento los valores por cada servicio, describo los motivos y registro los cambios de forma que se puedan seguir. De este modo, asiento las decisiones en el equipo y evito que, al cabo de unas semanas, se tenga que adivinar qu\u00e9 ha pasado. Antes de realizar actualizaciones o cambios en la arquitectura, reviso las curvas de evoluci\u00f3n para no endurecer o flexibilizar los par\u00e1metros a ciegas. Una peque\u00f1a fase de pruebas ahorra muchos problemas m\u00e1s adelante en producci\u00f3n. Este ritmo garantiza <strong>Constance<\/strong> en el d\u00eda a d\u00eda.<\/p>\n\n<h2>Ejercicio pr\u00e1ctico: Estructurar servidores de alojamiento web<\/h2>\n\n<p>Creo una cuenta espec\u00edfica para cada cliente <strong>cgroup<\/strong> y traslado all\u00ed PHP-FPM, la base de datos y la cach\u00e9. A cada conjunto le asigno \u00abmemory.max\u00bb m\u00e1s un margen, mientras que \u00abmemory.high\u00bb se activa antes y suaviza las fluctuaciones. Los servicios cr\u00edticos del cliente cuentan con l\u00edneas de protecci\u00f3n para que su memoria principal no se agote. Los registros y los paneles de control muestran qui\u00e9n frena, qui\u00e9n acelera y d\u00f3nde existe riesgo de OOM. Adem\u00e1s, las indicaciones sobre <a href=\"https:\/\/webhosting.de\/es\/servidor-contexto-aislamiento-namespaces-cgroups-alojamiento-seguridad\/\">Espacios de nombres y conceptos de aislamiento<\/a>, para que los clientes permanezcan claramente separados y <strong>Seguridad<\/strong> aumenta.<\/p>\n\n<p>Adem\u00e1s, ajusto el n\u00famero de trabajadores de PHP, los tama\u00f1os de OPcache y las cach\u00e9s de consultas para reducir el consumo de memoria. A menudo, el simple hecho de reducir los picos mediante memory.high ya acorta el tiempo de respuesta. Para las pruebas utilizo patrones de carga reales, no valores ideales sint\u00e9ticos. A continuaci\u00f3n, documento los nuevos l\u00edmites y los vinculo a los SLA. De este modo, la <strong>Transparencia<\/strong> frente a los clientes y al servicio de asistencia interna.<\/p>\n\n<h2>Soluci\u00f3n de problemas en la impresi\u00f3n de Memory<\/h2>\n\n<p>Aumenta <strong>memory.current<\/strong> De forma r\u00e1pida, lo primero que hago es comprobar si hay cambios en el tr\u00e1fico, en las implementaciones o en las configuraciones. Comparo las curvas de los picos de exceso de carga, los errores de p\u00e1gina y las latencias. Si se producen OOM de forma consecutiva, identifico los procesos afectados mediante el registro del kernel y ajusto los l\u00edmites o la carga de trabajo. Si la causa radica en cach\u00e9s defectuosas, realizo ajustes espec\u00edficos en lugar de aplicar una soluci\u00f3n global. Esta cadena de diagn\u00f3stico me lleva r\u00e1pidamente a la <strong>Causa<\/strong>, y no solo como un s\u00edntoma.<\/p>\n\n<p>Si la carga sigue siendo elevada, escalono el trabajo: establezco l\u00edmites de r\u00e1fagas para Ingress, reduzco la longitud de las colas y aplazo los trabajos por lotes. Al mismo tiempo, a corto plazo, aumento el valor de `memory.high` para ganar tiempo de margen sin tener que aumentar `memory.max`. Si detecto fugas de memoria, estrecho los l\u00edmites de seguridad hasta que haya una soluci\u00f3n. En casos persistentes, reduzco el alcance del servicio o replico la instancia. As\u00ed mantengo el <strong>Operaci\u00f3n<\/strong> Funciona de forma fiable, incluso bajo presi\u00f3n.<\/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>Automatizaci\u00f3n: medidas correctivas basadas en eventos<\/h2>\n\n<p>Hago nudos <strong>Acciones<\/strong> En cuanto a los eventos: `memory.events` proporciona contadores que proceso mediante un `Watcher` o una canalizaci\u00f3n de m\u00e9tricas. En caso de repetidas incidencias de \u00abhigh-hits\u00bb, vac\u00edo cach\u00e9s de forma selectiva, reduzco la concurrencia o inicio intentos de recuperaci\u00f3n antes de que los usuarios se den cuenta. Si las intervenciones moderadas fallan, recurro a medidas dr\u00e1sticas: suspensi\u00f3n de solicitudes, vaciado de colas, cambios en la priorizaci\u00f3n. Es importante que las decisiones <strong>determinista<\/strong> son \u2014los mismos desencadenantes, la misma reacci\u00f3n\u2014 para que los equipos puedan comprender y reproducir ese comportamiento.<\/p>\n\n<p>Adem\u00e1s, me quedo con la <strong>\u00c1mbito<\/strong> Con el OOM bajo control. Con memory.oom.group evito los cierres parciales que provocan que las aplicaciones entren en estados incoherentes. Si hay que cerrar algo, debe hacerse de forma coherente y r\u00e1pida, para que la capacidad restante vuelva a estar disponible cuanto antes. En combinaci\u00f3n con la telemetr\u00eda y los guiones de actuaci\u00f3n documentados, se crea un bucle de retroalimentaci\u00f3n robusto que funciona en condiciones reales de producci\u00f3n.<\/p>\n\n<h2>Perspectivas y resumen<\/h2>\n\n<p>El controlador de memoria de <strong>cgroup<\/strong> La versi\u00f3n 2 me ofrece un conjunto de herramientas escalonadas: l\u00edmites estrictos, frenos suaves y l\u00edneas de protecci\u00f3n con una prioridad clara. Si utilizo de forma consciente memory.max, memory.high, memory.low y memory.min, puedo reaccionar de forma ordenada ante picos de carga y mantener los servicios operativos. La supervisi\u00f3n mediante memory.current revela de forma temprana d\u00f3nde se alcanzan los l\u00edmites o faltan reservas. En entornos de contenedores y multitenant, estos mecanismos garantizan una asignaci\u00f3n equitativa de recursos sin efectos colaterales. Con disciplina, valores de medici\u00f3n y peque\u00f1os ajustes, consigo una <strong>Actuaci\u00f3n<\/strong> \u2013 desde una m\u00e1quina virtual individual hasta un servidor con una alta densidad de m\u00e1quinas virtuales.<\/p>","protected":false},"excerpt":{"rendered":"<p>Descubre c\u00f3mo funciona el controlador de memoria cgroup v2 de Linux y c\u00f3mo puedes crear entornos de alojamiento y contenedores estables mediante l\u00edmites espec\u00edficos de recursos en 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\/es\/wp-json\/wp\/v2\/posts\/21199","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/comments?post=21199"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21199\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/21192"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=21199"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=21199"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=21199"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}