{"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":"presion-de-memoria-kernel-de-linux-sistemas-de-alojamiento-optimizacion-ram","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/memory-pressure-linux-kernel-hosting-systeme-optimierung-ram\/","title":{"rendered":"Presi\u00f3n de memoria en el n\u00facleo de Linux: repercusiones en los sistemas de alojamiento web"},"content":{"rendered":"<p>La presi\u00f3n de memoria en el n\u00facleo de Linux afecta directamente a los sistemas de alojamiento: si la presi\u00f3n aumenta, el tiempo de CPU y las operaciones de E\/S se desplazan hacia tareas m\u00e1s exigentes <strong>Reclaim<\/strong>, los tiempos de respuesta se alargan y aumentan los riesgos de OOM. Explico claramente c\u00f3mo detecto, mido y mitigo la presi\u00f3n sobre la memoria, para que <strong>Alojamiento<\/strong>-Reaccionar de forma constante ante las cargas de trabajo.<\/p>\n\n<h2>Puntos centrales<\/h2>\n<p>Me centro en los factores clave que determinan el rendimiento y las interrupciones del servicio en los entornos de alojamiento web. Los siguientes puntos constituyen el hilo conductor en torno al cual oriento el diagn\u00f3stico y la optimizaci\u00f3n. Con esta visi\u00f3n general, evito interpretaciones err\u00f3neas de \u201eRAM llena\u201c e identifico los verdaderos <strong>Presi\u00f3n<\/strong> a tiempo.<\/p>\n<ul>\n  <li><strong>M\u00e9tricas PSI<\/strong> Muestran los tiempos de espera en lugar de la mera ocupaci\u00f3n y detectan los retrasos de forma temprana.<\/li>\n  <li><strong>Carga de swap<\/strong> indica problemas de recuperaci\u00f3n que agravan las operaciones de E\/S y las latencias.<\/li>\n  <li><strong>L\u00edmites de cgroups<\/strong> Controlar la limitaci\u00f3n, la protecci\u00f3n y el comportamiento en caso de OOM por servicio.<\/li>\n  <li><strong>Desplazamiento de la cach\u00e9<\/strong> Influye directamente en el rendimiento de la web y de las bases de datos.<\/li>\n  <li><strong>Planificaci\u00f3n de capacidades<\/strong> Y el ajuste mantiene el margen din\u00e1mico y evita el thrashing.<\/li>\n<\/ul>\n<p>As\u00ed es como estructuro mis an\u00e1lisis, desde el n\u00facleo hasta la aplicaci\u00f3n, y aplico las medidas adecuadas por orden de prioridad. La atenci\u00f3n se centra en los resultados medibles <strong>efectos<\/strong>, no al trabajo a destajo.<\/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>\u00bfQu\u00e9 significa \u00abMemory Pressure\u00bb en el n\u00facleo de Linux?<\/h2>\n\n<p>La \u201ecarga de memoria\u201c significa que el n\u00facleo dedica un tiempo apreciable a liberar memoria, en lugar de continuar con el trabajo de los procesos de usuario; la CPU dedica entonces m\u00e1s recursos a operaciones de lectura, escritura y expulsi\u00f3n, mientras las solicitudes quedan en espera. Distingo claramente entre \u201eRAM llena\u00bb y \u00abfalta de memoria utilizable\u00bb <strong>Espacio libre<\/strong>\u201c: Una cach\u00e9 \u201ellena\u201c es saludable; los cuellos de botella solo se producen cuando aumentan las inversiones en recuperaci\u00f3n. El n\u00facleo analiza las listas inactivas y escribe <strong>sucio<\/strong>-Elimina p\u00e1ginas, borra la cach\u00e9 de archivos y traslada las p\u00e1ginas an\u00f3nimas a la memoria externa en cuanto se superan los umbrales de Watermarks. El tiempo dedicado a estas actividades es decisivo; se refleja en las fases de espera de las tareas y en el aumento de los tiempos de respuesta. Un servidor puede funcionar de forma fluida con una utilizaci\u00f3n del 95 % seg\u00fan el modelo %, siempre que la cach\u00e9 se pueda recuperar f\u00e1cilmente, pero puede ralentizarse considerablemente con una baja carga de trabajo si es necesario desplazar p\u00e1ginas an\u00f3nimas activas.<\/p>\n\n<h2>Comprender y medir el PSI<\/h2>\n\n<p>La informaci\u00f3n sobre el estancamiento por presi\u00f3n (PSI) permite visualizar la presi\u00f3n de la memoria, ya que no mido la ocupaci\u00f3n, sino los retrasos. En <strong>\/proc\/presi\u00f3n\/memoria<\/strong> Veo \u201esome\u201c y \u201efull\u201c: \u201esome\u201c describe los momentos en los que al menos una tarea est\u00e1 a la espera de memoria, mientras que \u201efull\u201c indica las fases en las que todas est\u00e1n atascadas. Ejemplo: \u201esome avg10=4,67\u201c significa que, en los \u00faltimos 10 segundos, se produjeron 4,67 % de tiempo de paradas debido a cuellos de botella en la memoria; \u201efull avg10=0,30\u201c indica paradas completas poco frecuentes. Correlaciono los valores crecientes de \u201esome\u201c con los tiempos de respuesta en una fase temprana y escalo, ajusto o aligero la carga antes de que aparezcan errores graves de OOM. Esta perspectiva evita que me deje enga\u00f1ar por una RAM aparentemente \u201elibre\u201c, ya que las p\u00e1ginas libres sin acceso r\u00e1pido <strong>Reclaim<\/strong>-Aprovechan poco esa oportunidad.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Variable medida<\/th>\n      <th>Valor orientativo<\/th>\n      <th>S\u00edntoma<\/th>\n      <th>Acci\u00f3n<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Memoria PSI (promedio 10)<\/td>\n      <td>&gt; 2\u20133 % de forma continuada<\/td>\n      <td>Aumentan los tiempos de respuesta<\/td>\n      <td>Comprobar el margen de RAM, ajustar con precisi\u00f3n los l\u00edmites de los cgroups<\/td>\n    <\/tr>\n    <tr>\n      <td>Memoria PSI llena (avg10)<\/td>\n      <td>&gt; 0,1 % perceptible<\/td>\n      <td>Tiempos de inactividad breves<\/td>\n      <td>Identificar la causa, poner fin al thrashing<\/td>\n    <\/tr>\n    <tr>\n      <td>MemAvailable<\/td>\n      <td>&lt; 10 % de la RAM<\/td>\n      <td>Margen reducido<\/td>\n      <td>Aliviar la carga de la cach\u00e9 y la carga de trabajo, planificar la capacidad<\/td>\n    <\/tr>\n    <tr>\n      <td>vmstat si\/so<\/td>\n      <td>permanente &gt; 0<\/td>\n      <td>Presi\u00f3n de intercambio<\/td>\n      <td>Ajustar Swappiness\/Swap, proteger 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>S\u00edntomas en entornos de alojamiento web<\/h2>\n\n<p>En servidores muy activos, lo primero que observo son picos de latencia, mientras que la carga de la CPU parece mantenerse moderada; el kernel se encuentra en bucles de recuperaci\u00f3n, las operaciones de E\/S se acumulan y las solicitudes quedan en espera. La media de carga sube, aunque los n\u00facleos parecen estar libres, porque muchas tareas se bloquean en la memoria o en las E\/S; este es un indicio clave de un aumento de <strong>Impresiones<\/strong>. Los valores persistentes de \u00absi\/so\u00bb en vmstat indican que el sistema est\u00e1 realizando operaciones de intercambio de memoria de forma activa, lo que ralentiza los handshakes de TLS, los contenidos din\u00e1micos y las rutas de consulta. Si no se soluciona, el sistema entra en \u00abthrashing\u00bb: la CPU dedica la mayor parte del tiempo a la paginaci\u00f3n y al intercambio de memoria, en lugar de realizar tareas \u00fatiles. En una situaci\u00f3n de escalada, el \u00abOOM-Killer\u00bb interviene y termina los procesos con una puntuaci\u00f3n elevada; una medida espec\u00edfica <a href=\"https:\/\/webhosting.de\/es\/oom-killer-linux-memoria-falta-de-memoria-analisis-alojamiento-web\/\">An\u00e1lisis del OOM-Killer<\/a> Me ayuda a detectar patrones y errores de configuraci\u00f3n.<\/p>\n\n<h2>Importancia para las cargas de trabajo de alojamiento y los cgroups<\/h2>\n\n<p>En entornos compartidos, basta con unas pocas aplicaciones que consuman muchos recursos de memoria para aumentar las latencias de muchos clientes; los cgroups mitigan los efectos, pero no solucionan el problema de un dimensionamiento incorrecto <strong>Instancias<\/strong>. En los VPS y las instancias en la nube, una memoria RAM escasa o una estrategia de intercambio deficiente provocan picos de carga m\u00e1s r\u00e1pidamente; el aislamiento protege a los dem\u00e1s, pero no al propio servicio. Las bases de datos dependen de grandes grupos de b\u00faferes; si Reclaim los desplaza o interviene el intercambio, los tiempos de consulta aumentan y el rendimiento se reduce significativamente. Las orquestaciones de contenedores utilizan memory.low, memory.high y memory.max para proteger servicios importantes, mitigar los bloqueos y, en caso de emergencia, terminarlos de forma selectiva. Por eso elijo los l\u00edmites de forma consciente y superviso el PSI por servicio, para poder tomar medidas correctivas a tiempo y reservar recursos para los servicios cr\u00edticos <strong>Cargas de trabajo<\/strong> mantenerlo despejado.<\/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>Estrategia de seguimiento y m\u00e9tricas<\/h2>\n\n<p>Consulto los valores de MemAvailable, Buffers y Cached para entender cu\u00e1nta memoria se puede recuperar a corto plazo; los valores de MemFree por s\u00ed solos pueden llevar f\u00e1cilmente a conclusiones err\u00f3neas. Al mismo tiempo, consulto vmstat: unos valores de si\/so persistentes indican presi\u00f3n de swap, lo que dispara enormemente la E\/S y aumenta las latencias; para m\u00e1s informaci\u00f3n sobre <a href=\"https:\/\/webhosting.de\/es\/uso-de-swap-rendimiento-del-servidor-alojamiento-optimus\/\">Utilizaci\u00f3n de swaps<\/a> Utilizo patrones de diagn\u00f3stico contrastados. PSI me proporciona el elemento que me faltaba, ya que \u201esome\u201c y \u201efull\u201c cuantifican los retrasos reales; activo alertas cuando se superan los umbrales y distingo los picos de carga de los cuellos de botella cr\u00f3nicos. Las series temporales obtenidas a trav\u00e9s de sar o de la pila de observabilidad hacen visibles los patrones y me ayudan a confirmar los resultados del ajuste. dmesg revela eventos OOM que indican l\u00edmites estrictos o configuraciones err\u00f3neas; as\u00ed construyo una imagen coherente desde la perspectiva del kernel, el comportamiento de E\/S y <strong>Aplicaci\u00f3n<\/strong>.<\/p>\n\n<h2>Cargas de trabajo t\u00edpicas bajo presi\u00f3n<\/h2>\n\n<p>Los servidores web como Nginx o Apache sirven el contenido m\u00e1s lentamente cuando Reclaim y Swap se ejecutan en segundo plano; las conexiones Keep-Alive permanecen abiertas durante m\u00e1s tiempo, lo que agrava las colas. Las pilas de PHP y Python ocupan memoria RAM debido a las cach\u00e9s de los frameworks, las partes JIT y los datos de sesi\u00f3n; en caso de desplazamiento, estos datos oscilan entre la RAM y el almacenamiento y alargan considerablemente los tiempos de respuesta. Las bases de datos pierden velocidad en cuanto los grupos de b\u00faferes se reducen o parte de su contenido acaba en el swap; incluso una latencia adicional m\u00ednima por operaci\u00f3n de E\/S se acumula cuando hay muchas <strong>Consultas<\/strong>. Los servicios de almacenamiento en cach\u00e9, como Redis o Memcached, necesitan que las operaciones se realicen en la memoria RAM; si las \u00e1reas de claves acaban en el espacio de intercambio, la ventaja se pierde y aumenta el riesgo de que se interrumpan en momentos de mayor carga. En todos los casos, las m\u00e9tricas de PSI y del espacio de intercambio ofrecen las indicaciones m\u00e1s claras de que la memoria se ha convertido en un cuello de botella, y no las <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>Optimizaci\u00f3n del sistema y par\u00e1metros del n\u00facleo<\/h2>\n\n<p>Empiezo por vm.swappiness: un ajuste moderadamente reducido evita un uso excesivo del swap sin bloquear la recuperaci\u00f3n necesaria; mido los efectos de forma sistem\u00e1tica con PSI. A continuaci\u00f3n, optimizo vm.dirty_ratio y los l\u00edmites relacionados, para no provocar largas oleadas de vaciado y, al mismo tiempo, no generar un exceso de operaciones de escritura menores; ambas cosas tienen un efecto notable <strong>Efectos<\/strong> en cuanto a latencias. En Cgroups v2 configuro \u00abmemory.low\u00bb para servicios cr\u00edticos, \u00abmemory.high\u00bb para la limitaci\u00f3n en caso de sobrecarga y \u00abmemory.max\u00bb como l\u00edmite estricto con OOM controlables. Presto especial atenci\u00f3n a las topolog\u00edas NUMA: puede producirse presi\u00f3n local aunque a\u00fan quede RAM libre a nivel global; la vinculaci\u00f3n de procesos y memoria mitiga este tipo de trampas. Por \u00faltimo, compruebo el comportamiento de la cach\u00e9 de p\u00e1ginas; el desplazamiento innecesario reduce las tasas de acierto y supone una p\u00e9rdida de tiempo inmediata en cargas de trabajo web y de bases de datos, a lo que se suma la <a href=\"https:\/\/webhosting.de\/es\/servidor-pagina-cache-desalojo-linux-memoria-impresion-optimizacion-insight\/\">Optimizaci\u00f3n de la cach\u00e9 de p\u00e1ginas<\/a> ofrece informaci\u00f3n \u00fatil.<\/p>\n\n<h2>An\u00e1lisis en profundidad de las rutas de Reclaim<\/h2>\n<p>Para elegir las medidas adecuadas, distingo entre: <strong>kswapd<\/strong> y <strong>Recuperaci\u00f3n directa<\/strong>. kswapd funciona de forma as\u00edncrona cuando se caen por debajo de los umbrales; es relativamente suave siempre que haya suficiente cach\u00e9 f\u00e1cilmente recuperable. Direct Reclaim interviene de forma s\u00edncrona en los contextos de ejecuci\u00f3n cuando los hilos necesitan p\u00e1ginas de forma urgente; es aqu\u00ed donde se producen los atascos perceptibles para los usuarios. Observo si la recuperaci\u00f3n afecta m\u00e1s a la cach\u00e9 de archivos o a las p\u00e1ginas an\u00f3nimas: si el n\u00facleo desplaza principalmente la cach\u00e9 de archivos, aumentan las faltas de cach\u00e9; si desplaza la memoria an\u00f3nima (p. ej., el mont\u00f3n), existe el riesgo de paradas bruscas y actividad de intercambio. Los mecanismos modernos de conjunto de trabajo tienen en cuenta las distancias de re-fallo para mantener las p\u00e1ginas \u00fatiles durante m\u00e1s tiempo; si, a pesar de ello, observo muchos re-fallos repetidos, s\u00e9 que los conjuntos activos son mayores que el espacio disponible <strong>Espacio libre<\/strong> se han convertido en.<\/p>\n<p>Adem\u00e1s, tengo en cuenta la compactaci\u00f3n y la desfragmentaci\u00f3n: <strong>kcompactd<\/strong> intenta crear \u00e1reas contiguas, por ejemplo, para grandes asignaciones o <strong>THP<\/strong>. Si la compactaci\u00f3n se retrasa, observo un mayor consumo de CPU en kcompactd, latencias crecientes y un aumento de los valores \u201efull\u201c de PSI en los picos de carga. En estos casos, suele ser m\u00e1s sensato reducir la carga o ajustar las pol\u00edticas de THP, en lugar de limitarse a \u201eaumentar el swap\u201c.<\/p>\n\n<h2>Estrategias de swap en detalle<\/h2>\n<p>El swap no es un enemigo, sino una herramienta; sin embargo, si se utiliza incorrectamente, puede aumentar la latencia. Distingo entre:<\/p>\n<ul>\n  <li><strong>Sin swap<\/strong>: A salvo frente a los retrasos en el intercambio, pero arriesgado en los picos: los OOM se producen antes y Reclaim no dispone de un margen de seguridad.<\/li>\n  <li><strong>Swap moderado<\/strong> En un SSD r\u00e1pido: ideal para almacenar p\u00e1ginas an\u00f3nimas inactivas; protege los conjuntos activos en la RAM si los par\u00e1metros de swappiness y los l\u00edmites de cgroup se configuran adecuadamente.<\/li>\n  <li><strong>zswap\/zram<\/strong>: La compresi\u00f3n alivia la carga de E\/S; es adecuada para hosts con poca actividad de E\/S o como amortiguador frente a picos de carga moment\u00e1neos. Compruebo la capacidad de la CPU y la tasa de compresi\u00f3n para evitar que la CPU se vea ralentizada.<\/li>\n<\/ul>\n<p>No configuro el valor de swappiness en un nivel bajo de forma generalizada; en cargas de trabajo con una cach\u00e9 de archivos grande, conviene establecer un valor de swappiness algo m\u00e1s alto para descartar p\u00e1ginas an\u00f3nimas inactivas y mantener estable la cach\u00e9 de archivos. Protejo los servicios cr\u00edticos (por ejemplo, las bases de datos) con \u00abmemory.low\u00bb y, si es necesario, bloqueando sus conjuntos activos en la RAM, para que el intercambio no afecte a lo que no debe. Lo fundamental es que <strong>vmstat si\/so<\/strong> y el PSI descienda de forma constante cuando ajuste la estrategia; de lo contrario, har\u00e9 los ajustes necesarios.<\/p>\n\n<h2>THP, compactaci\u00f3n y fragmentaci\u00f3n<\/h2>\n<p><strong>P\u00e1ginas transparentes enormes (THP)<\/strong> Ahorran accesos a la TLB y ayudan a las aplicaciones que suponen una gran carga para la CPU y consumen mucha memoria. Sin embargo, bajo presi\u00f3n, provocan trabajo de compactaci\u00f3n; en ese caso, la opci\u00f3n \u201ealways\u201c puede provocar grandes atascos. Utilizo \u201emadvise\u201c de forma selectiva para cargas de trabajo que se benefician de ello (por ejemplo, determinados motores en memoria) y, en el caso de las pilas web sensibles a la latencia, prefiero desactivar THP de forma selectiva o habilitarlo \u00fanicamente mediante madvise. Adem\u00e1s, observo <strong>vm.compaction_proactiveness<\/strong> y comprueba si la compactaci\u00f3n proactiva retrasa la formaci\u00f3n de estercol o si realmente la reduce. Si las p\u00e1ginas de THP se fragmentan con frecuencia o la compactaci\u00f3n se acelera demasiado, eso indica que hay muy poco <strong>Espacio libre<\/strong> o patrones de asignaci\u00f3n inadecuados en la aplicaci\u00f3n.<\/p>\n\n<h2>Trampas NUMA e impresi\u00f3n local<\/h2>\n<p>En los hosts NUMA, la \u201eRAM libre\u201c global es enga\u00f1osa: un socket puede estar saturado, mientras que otro permanece sin utilizar. Compruebo las estad\u00edsticas NUMA y anclo los procesos localmente (vinculaci\u00f3n de CPU\/memoria) para que los conjuntos activos permanezcan cerca de la carga de c\u00e1lculo. La recuperaci\u00f3n directa en un nodo, a pesar de las reservas globales, indica desequilibrios NUMA; en estos casos, resultan \u00fatiles las asignaciones intercaladas para servicios muy dispersos o la vinculaci\u00f3n estricta para cargas de trabajo monol\u00edticas. El PSI por cgroup, combinado con las estad\u00edsticas NUMA, me indica si un \u00fanico nodo es el responsable de generar las colas.<\/p>\n\n<h2>Medidas relacionadas con la aplicaci\u00f3n<\/h2>\n\n<p>Analizo los perfiles de memoria con ps, top, htop y herramientas de perfilado para detectar los verdaderos devoradores de memoria y las fugas; al hacerlo, presto atenci\u00f3n a c\u00f3mo evolucionan los hotsets a lo largo del tiempo. Elijo las cach\u00e9s de las aplicaciones de forma deliberada: si son demasiado grandes, generan presi\u00f3n; si son demasiado peque\u00f1as, se sacrifica la velocidad; realizo los ajustes bas\u00e1ndome en el PSI y los tiempos de respuesta, no en corazonadas. Ante se\u00f1ales de presi\u00f3n detectadas, la aplicaci\u00f3n puede liberar voluntariamente cach\u00e9s menos cr\u00edticas o datos temporales; de este modo, reduzco los bloqueos sin tener que modificar los l\u00edmites globales. Ajusto los par\u00e1metros de inicio y la configuraci\u00f3n del GC (por ejemplo, para las JVM) de manera que los conjuntos de trabajo se mantengan correctamente en la RAM; mitigo los patrones de asignaci\u00f3n agresivos mediante el procesamiento por lotes. Tambi\u00e9n vigilo los artefactos de compilaci\u00f3n y los s\u00edmbolos de depuraci\u00f3n, ya que los restos que se pasan por alto suponen un coste oculto <strong>Memoria<\/strong> y aumentan el riesgo de que se produzcan paradas 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>Matices de cgroups v2 y estrategias OOM<\/h2>\n<p>Con Cgroups v2 separo claramente la protecci\u00f3n, la limitaci\u00f3n y los l\u00edmites estrictos: <strong>memoria.baja<\/strong> Reserva margen de capacidad para los servicios cr\u00edticos; el resto se destina a grupos menos importantes. <strong>memoria.alta<\/strong> Cuando se supera el l\u00edmite, reduce el rendimiento de forma selectiva y obliga a las aplicaciones a liberar memoria antes de que el sistema se vea afectado. <strong>memoria.max<\/strong> Es la \u00faltima l\u00ednea de defensa: si se supera, se produce un OOM en un entorno controlado. Configuro <strong>PSI<\/strong> por cada cgroup, para que las alertas se activen all\u00ed donde se producen los bloqueos; el PSI global se mantiene estable mientras un \u00fanico servicio se colapsa \u2014y es precisamente este patr\u00f3n el que quiero detectar\u2014. Junto con las prioridades OOM, establezco reglas de sacrificio claras: los trabajadores por lotes sin importancia se cierran primero, mientras que las API del n\u00facleo conservan su <strong>Espacio libre<\/strong>.<\/p>\n\n<h2>Virtualizaci\u00f3n: \u00abballooning\u00bb, KSM y \u00abovercommit\u00bb<\/h2>\n<p>En entornos virtualizados me enfrento a una doble presi\u00f3n: el sistema invitado parece detectar memoria RAM libre, mientras que el hipervisor, a trav\u00e9s de <strong>Vuelo en globo<\/strong> . Esta jugada aumenta los costes de recuperaci\u00f3n para ambas partes. Mido el PSI en el invitado y lo correlaciono con las m\u00e9tricas del hipervisor; si el PSI aumenta durante los eventos de \u00abballooning\u00bb, la m\u00e1quina virtual necesita m\u00e1s capacidad garantizada o mejores pol\u00edticas de Cgroup en el host. <strong>KSM<\/strong> Ahorra memoria RAM gracias a la deduplicaci\u00f3n de p\u00e1ginas id\u00e9nticas, pero consume recursos de la CPU; en entornos de alojamiento con muchas m\u00e1quinas virtuales similares, puede merecer la pena siempre que la carga adicional de la CPU no ponga en riesgo los SLO. Solo planeo el overcommit (por ejemplo, la asignaci\u00f3n agresiva de muchas m\u00e1quinas virtuales peque\u00f1as) con reservas fijas de SLO y una estricta <strong>memoria.baja<\/strong> para sistemas en los que la latencia es un factor cr\u00edtico.<\/p>\n\n<h2>Decisiones de arquitectura en el alojamiento web<\/h2>\n\n<p>Apuesto por la distribuci\u00f3n horizontal para que las instancias individuales sufran menos picos de carga; los grupos escalables amortiguan los picos extremos y mantienen las latencias m\u00e1s bajas. Separo claramente las funciones: las bases de datos, la aplicaci\u00f3n y el almacenamiento en cach\u00e9 cuentan con sus propios grupos de recursos, para que los procesos de recuperaci\u00f3n no generen efectos secundarios inesperados m\u00e1s all\u00e1 de los l\u00edmites del sistema. Elijo el almacenamiento teniendo en cuenta la latencia de escritura, ya que los vaciados de p\u00e1ginas sucias repercuten directamente en los tiempos de respuesta; una ruta r\u00e1pida reduce notablemente los tiempos de recuperaci\u00f3n. En los cl\u00fasteres, preveo reservas de RAM por nodo y las controlo mediante pol\u00edticas de programador, para que la carga y el consumo de memoria se distribuyan de forma m\u00e1s uniforme. Automatizo el escalado con umbrales PSI, de modo que el aumento de los valores \u201esome\u201c desencadene acciones antes de que se produzcan frenadas bruscas y <strong>Matar<\/strong>-suceden.<\/p>\n\n<h2>Planificaci\u00f3n de la capacidad y modelos de margen de capacidad<\/h2>\n<p>Defino el margen de seguridad de forma cuantificable: mantengo reservas suficientes para que el \u201esome\u201c PSI se mantenga por debajo de los umbrales definidos en picos normales y para que el \u201efull\u201c pr\u00e1cticamente no se produzca. Para ello utilizo percentiles (por ejemplo, el percentil 99 de la carga horaria) y preveo entre 10 y 30 % de RAM adicional, dependiendo de la volatilidad de la carga de trabajo. Las bases de datos reciben reservas fijas m\u00e1s grandes, mientras que las interfaces web se escalan de forma m\u00e1s din\u00e1mica. Calibro los tiempos de recuperaci\u00f3n: \u00bfa qu\u00e9 velocidad descienden el PSI y el si\/so tras un pico? Si se mantienen elevados, es se\u00f1al de que las reservas son insuficientes o de que la estrategia de intercambio\/datos sucios no es adecuada. De este modo, la planificaci\u00f3n de la capacidad se convierte en un proceso continuo en lugar de una estimaci\u00f3n anual.<\/p>\n\n<h2>Avisos y ajuste controlado por SLO<\/h2>\n<p>Vinculo PSI con los SLO de los usuarios: si \u201esome avg10\u201c aumenta al mismo tiempo que las latencias de la API, intervengo. Clasifico las alertas en \u201eamarillo\u201c (2-3 % \u201esome\u201c continuos, \u201efull\u201c cercano a 0) y \u201erojo\u201c (m\u00e1s de 5 % \u201esome\u201c o \u201efull\u201c &gt; 0,1 %). Las alertas basadas en cgroups ayudan a aislar a la minor\u00eda ruidosa. Adem\u00e1s, configuro alertas ante el aumento de las colas sucias y los tiempos de espera de escritura, para poder suavizar las oleadas de datos sucios a tiempo. El objetivo es que las medidas de ajuste (swappiness, memory.high, tama\u00f1os de cach\u00e9) sean observables y reversibles; implemento los cambios de forma gradual y comparo los resultados antes y despu\u00e9s utilizando las mismas m\u00e9tricas.<\/p>\n\n<h2>Diagn\u00f3stico paso a paso en el d\u00eda a d\u00eda<\/h2>\n\n<p>Primero compruebo \u201efree -h\u201c y \u201eMemAvailable\u201c: si el valor desciende notablemente, busco cach\u00e9s que se puedan liberar de forma razonable y servicios con \u00abhotsets\u00bb crecientes. A continuaci\u00f3n, ejecuto \u00abvmstat\u00bb a intervalos cortos para detectar tendencias, por si acaso; el intercambio persistente confirma la presi\u00f3n y me lleva a la ruta de E\/S. A continuaci\u00f3n, leo \/proc\/pressure\/memory y eval\u00fao los valores \u00absome\u00bb y \u00abfull\u00bb a lo largo de 10, 60 y 300 segundos; relaciono directamente los valores medios crecientes con las latencias observadas. dmesg me muestra rastros de OOM y revela qu\u00e9 procesos han provocado o sufrido crisis de memoria recientemente; a partir de ah\u00ed deduzco los l\u00edmites y las prioridades para los cgroups. A partir de todo ello, formulo una hip\u00f3tesis, aplico peque\u00f1os ajustes, verifico con PSI y mantengo la <strong>Tiempo de respuesta<\/strong> de un vistazo.<\/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>Manuales de procedimientos y cadenas de causas t\u00edpicas<\/h2>\n<p>Hay algunos patrones que se repiten una y otra vez:<\/p>\n<ul>\n  <li><strong>Las tareas de copia de seguridad o de escaneo desplazan la cach\u00e9 de p\u00e1ginas<\/strong>: De repente, bajan las tasas de aciertos de la cach\u00e9 y la web y la base de datos se ralentizan. Medida: reducir la carga de los trabajos (prioridad de E\/S), desplazar las franjas horarias, establecer \u00abmemory.high\u00bb para el cgroup de los trabajos y proteger el presupuesto de la cach\u00e9 de p\u00e1ginas de los servicios cr\u00edticos.<\/li>\n  <li><strong>Fugas en los procesos de los trabajadores<\/strong>: Aumento gradual de la memoria an\u00f3nima; el PSI \u201esome\u201c va subiendo a lo largo de varias horas. Medida: identificar la fuga, implantar pol\u00edticas de reinicio autom\u00e1tico y reciclaje, y establecer l\u00edmites de memoria para que las fugas no pongan en peligro todo el host.<\/li>\n  <li><strong>Estancamientos debidos al THP<\/strong>: La carga de kcompactd aumenta durante los picos de tr\u00e1fico. Medida: configurar THP en \u201emadvise\u201c, ajustar los servicios afectados, comprobar los par\u00e1metros de compactaci\u00f3n y aumentar el margen de capacidad.<\/li>\n  <li><strong>Impresi\u00f3n local NUMA<\/strong>: Un socket se satura, aunque hay memoria RAM libre a nivel global. Medida: corregir las afinidades, aplicar el interleave para cargas de trabajo muy dispersas y ajustar el reparto de carga en el programador.<\/li>\n  <li><strong>Memoria virtual en discos lentos<\/strong>: si\/so aumenta, los tiempos de respuesta se disparan. Medida: trasladar el swap a un almacenamiento m\u00e1s r\u00e1pido, evaluar zswap\/zram, ajustar el valor de swappiness y las pol\u00edticas de cgroup.<\/li>\n<\/ul>\n<p>Cada runbook termina con una validaci\u00f3n: \u00bfse producen \u201esome\/full\u201c y se estabilizan las latencias? Si no es as\u00ed, la hip\u00f3tesis era err\u00f3nea o incompleta, por lo que sigo iterando.<\/p>\n\n<h2>Herramientas y trazado en la empresa<\/h2>\n<p>Adem\u00e1s de las herramientas cl\u00e1sicas, apuesto por un an\u00e1lisis m\u00e1s detallado: observo las relaciones entre la cach\u00e9 de p\u00e1ginas y los datos an\u00f3nimos, las tasas de fallos de p\u00e1gina, los patrones de re-fallos y las colas de reescritura. Los enfoques basados en eBPF y el rastreo me indican con precisi\u00f3n d\u00f3nde se producen los tiempos de espera, por ejemplo, a lo largo de las rutas de recuperaci\u00f3n, en la reescritura o en la asignaci\u00f3n de bloques grandes. Para m\u00ed es importante contar con una instrumentaci\u00f3n eficiente y apta para producci\u00f3n: ventanas de activaci\u00f3n cortas, muestreo en lugar de registro continuo y una correlaci\u00f3n clara con las m\u00e9tricas de la aplicaci\u00f3n. As\u00ed puedo identificar las causas antes de realizar ajustes generalizados en los par\u00e1metros.<\/p>\n\n<h2>Puntos clave y pr\u00f3ximos pasos<\/h2>\n\n<p>La \u00abpresi\u00f3n de memoria\u00bb describe el tiempo perdido debido a la escasez de memoria, no solo a la RAM ocupada; la mido con PSI, detecto las tendencias con antelaci\u00f3n y act\u00fao bas\u00e1ndome en los datos. Quien analice conjuntamente MemAvailable, vmstat (tanto en modo si como en modo so), PSI y dmesg, descubrir\u00e1 las verdaderas causas de los picos de latencia y el thrashing. Mediante el ajuste de los par\u00e1metros de swappiness, dirty y cgroup, reduzco los bloqueos de forma selectiva y garantizo a los servicios importantes su <strong>Espacio libre<\/strong>. A nivel de arquitectura, la distribuci\u00f3n horizontal, la clara divisi\u00f3n de funciones y las rutas de almacenamiento r\u00e1pidas mitigan las consecuencias de cualquier pico de carga. Al final, lo que cuenta es que vincule continuamente el diagn\u00f3stico y las medidas correctivas: medir, ajustar, volver a medir\u2026 hasta que el rendimiento y <strong>Estabilidad<\/strong> volver a encajar.<\/p>","protected":false},"excerpt":{"rendered":"<p>Descubre c\u00f3mo la presi\u00f3n de memoria en el n\u00facleo de Linux afecta al rendimiento del alojamiento, c\u00f3mo funcionan las m\u00e9tricas PSI y qu\u00e9 optimizaciones son necesarias para la memoria del 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":"98","_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\/es\/wp-json\/wp\/v2\/posts\/20212","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=20212"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20212\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/20205"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=20212"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=20212"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=20212"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}