{"id":21026,"date":"2026-08-26T15:05:23","date_gmt":"2026-08-26T13:05:23","guid":{"rendered":"https:\/\/webhosting.de\/linux-transparent-page-cache-page-cache-unterschiede-optimierung-datencache\/"},"modified":"2026-08-26T15:05:23","modified_gmt":"2026-08-26T13:05:23","slug":"linux-cache-de-paginas-transparente-diferencias-entre-caches-de-paginas-optimizacion-cache-de-datos","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/linux-transparent-page-cache-page-cache-unterschiede-optimierung-datencache\/","title":{"rendered":"Cach\u00e9 de p\u00e1ginas transparente de Linux: conceptos b\u00e1sicos y diferencias con respecto a la cach\u00e9 de p\u00e1ginas cl\u00e1sica"},"content":{"rendered":"<p>En dos frases voy a explicar c\u00f3mo Linux acelera el acceso a los archivos en la RAM y c\u00f3mo un <strong>cach\u00e9 de p\u00e1ginas transparente<\/strong> que utiliza unidades de p\u00e1gina m\u00e1s grandes para reducir la carga administrativa. Adem\u00e1s, explico las diferencias con respecto a la cach\u00e9 de p\u00e1gina cl\u00e1sica con p\u00e1ginas de 4 KiB, as\u00ed como el efecto sobre la TLB, la fragmentaci\u00f3n y el comportamiento de la carga de trabajo.<\/p>\n\n<h2>Puntos centrales<\/h2>\n\n<ul>\n  <li><strong>Tama\u00f1o de la p\u00e1gina<\/strong>: 4 KiB frente a 2 MiB influye en la granularidad y la eficiencia.<\/li>\n  <li><strong>Impresi\u00f3n TLB<\/strong>: Las p\u00e1ginas grandes reducen el n\u00famero de entradas, mientras que las peque\u00f1as mantienen su flexibilidad.<\/li>\n  <li><strong>Fragmentaci\u00f3n<\/strong>: Las p\u00e1ginas grandes necesitan memoria RAM contigua.<\/li>\n  <li><strong>Cargas de trabajo<\/strong>: En orden secuencial, los grandes se benefician m\u00e1s; los peque\u00f1os, por casualidad, menos.<\/li>\n  <li><strong>Controlar<\/strong>: Probar, medir y, a continuaci\u00f3n, configurar paso a paso.<\/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\/linux-serverraum-8473.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>\u00bfQu\u00e9 es la cach\u00e9 de p\u00e1ginas cl\u00e1sica de Linux?<\/h2>\n\n<p>La cach\u00e9 de p\u00e1ginas cl\u00e1sica almacena en la memoria RAM las p\u00e1ginas de archivos que se utilizan con frecuencia, de modo que los accesos de lectura se realizan directamente desde <strong>RAM<\/strong> se lleva a cabo. Normalmente trabaja con p\u00e1ginas de 4 KiB y gestiona cada p\u00e1gina como una unidad independiente en la cach\u00e9. De este modo, muchos archivos peque\u00f1os o partes muy solicitadas de archivos grandes permanecen disponibles sin sobrecargar el SSD o el HDD. El n\u00facleo da prioridad a las p\u00e1ginas activas, descarta el contenido poco utilizado y, de este modo, reacciona de forma din\u00e1mica ante los picos de carga. Para obtener informaci\u00f3n m\u00e1s detallada, remito a una introducci\u00f3n concisa sobre la <a href=\"https:\/\/webhosting.de\/es\/optimizador-del-rendimiento-de-la-cache-de-paginas-de-linux\/\">Rendimiento de la cach\u00e9 de p\u00e1ginas<\/a>, que describe el principio b\u00e1sico de forma pr\u00e1ctica.<\/p>\n\n<h2>\u00bfPor qu\u00e9 una cach\u00e9 de p\u00e1ginas transparente?<\/h2>\n\n<p>Un gran n\u00famero de p\u00e1ginas individuales de 4 KiB genera trabajo administrativo y aumenta la presi\u00f3n sobre la <strong>TLB<\/strong>. Las p\u00e1ginas m\u00e1s grandes, como las de 2 MiB, pueden cubrir el mismo espacio de direcciones con menos entradas y, de este modo, ahorrar tiempo de CPU. Una cach\u00e9 de p\u00e1ginas transparente agrupa autom\u00e1ticamente las p\u00e1ginas de los archivos en unidades m\u00e1s grandes cuando los patrones de acceso y la ubicaci\u00f3n en memoria lo permiten. Esto se asemeja a la idea que subyace a las \u00abTransparent Huge Pages\u00bb, pero en este caso se refiere a una cach\u00e9 basada en archivos en lugar de a memoria an\u00f3nima. Solo utilizo este tipo de funciones despu\u00e9s de haber comprendido los patrones de acceso, la fragmentaci\u00f3n y los requisitos de latencia, ya que las p\u00e1ginas m\u00e1s grandes aumentan la granularidad.<\/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\/LinuxPageCacheMeeting4321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comparar las diferencias de forma sistem\u00e1tica<\/h2>\n\n<p>Para que quede claro, voy a comparar las caracter\u00edsticas m\u00e1s importantes de la cach\u00e9 cl\u00e1sica, la cach\u00e9 de p\u00e1ginas transparente y el THP, para que la elecci\u00f3n se haga en funci\u00f3n de <strong>Carga de trabajo<\/strong> resulta m\u00e1s sencillo. Nos centramos en el tama\u00f1o de la p\u00e1gina, la TLB, la fragmentaci\u00f3n, las ventajas y los riesgos. La tabla muestra los puntos fuertes y las limitaciones sin frases publicitarias. La leo de izquierda a derecha y compruebo qu\u00e9 columna se ajusta mejor a la carga. A continuaci\u00f3n, decido si me quedo con la cach\u00e9 de 4 KiB o pruebo con p\u00e1ginas m\u00e1s grandes.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Caracter\u00edstica<\/th>\n      <th>Cach\u00e9 de p\u00e1ginas cl\u00e1sico (4 KiB)<\/th>\n      <th>Cach\u00e9 de p\u00e1gina transparente (por ejemplo, 2 MiB)<\/th>\n      <th>THP (memoria an\u00f3nima)<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Tama\u00f1o de p\u00e1gina\/granularidad<\/td>\n      <td>Almacenamiento en cach\u00e9 preciso y minucioso<\/td>\n      <td>A grandes rasgos, \u00e1reas muy amplias<\/td>\n      <td>Aproximadamente, grandes montones\/pilas<\/td>\n    <\/tr>\n    <tr>\n      <td>Impresi\u00f3n TLB<\/td>\n      <td>M\u00e1s alto gracias a las numerosas entradas<\/td>\n      <td>M\u00e1s abajo, menos entradas<\/td>\n      <td>M\u00e1s abajo, menos entradas<\/td>\n    <\/tr>\n    <tr>\n      <td>Gastos administrativos<\/td>\n      <td>Muy alto en muchas p\u00e1ginas<\/td>\n      <td>Menos metadatos<\/td>\n      <td>Menos metadatos<\/td>\n    <\/tr>\n    <tr>\n      <td>Fragmentaci\u00f3n<\/td>\n      <td>No es cr\u00edtico, no requiere contig\u00fcidad<\/td>\n      <td>Requiere memoria RAM contigua<\/td>\n      <td>Requiere memoria RAM contigua<\/td>\n    <\/tr>\n    <tr>\n      <td>Cargas adecuadas<\/td>\n      <td>Archivos peque\u00f1os, accesos aleatorios<\/td>\n      <td>Archivos de gran tama\u00f1o, patrones secuenciales<\/td>\n      <td>Heaps grandes, bases de datos en la RAM<\/td>\n    <\/tr>\n    <tr>\n      <td>Riesgos<\/td>\n      <td>Mayor sobrecarga de la TLB y la CPU<\/td>\n      <td>Overfetch, picos de latencia en Split\/Merge<\/td>\n      <td>Overfetch, picos de latencia en Split\/Merge<\/td>\n    <\/tr>\n    <tr>\n      <td>Dependencia del n\u00facleo\/de las caracter\u00edsticas<\/td>\n      <td>Ampliamente disponible<\/td>\n      <td>Tener en cuenta la versi\u00f3n\/implementaci\u00f3n<\/td>\n      <td>Comprobar la configuraci\u00f3n de distribuci\u00f3n<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>La tabla no sustituye a una prueba, sino que estructura mi <strong>Decisi\u00f3n<\/strong>. En primer lugar, eval\u00fao los patrones de acceso y el tama\u00f1o de los archivos. A continuaci\u00f3n, mido la latencia, el tiempo de CPU y la tasa de aciertos de la cach\u00e9 con y sin p\u00e1ginas grandes. Si las pruebas de rendimiento muestran ventajas claras sin valores at\u00edpicos, ampl\u00edo la escala con cautela. Si se producen picos, retrocedo o limito su uso.<\/p>\n\n<h2>C\u00f3mo crea el n\u00facleo p\u00e1ginas de archivo de gran tama\u00f1o<\/h2>\n\n<p>Para que se generen unidades de p\u00e1gina m\u00e1s grandes en la cach\u00e9 de p\u00e1ginas, el n\u00facleo necesita \u00e1reas contiguas de archivos en la memoria y un acceso suficientemente coherente. Un ejemplo t\u00edpico es la \u00abpromoci\u00f3n\u00bb: varias p\u00e1ginas de 4 KiB se agrupan en un folio m\u00e1s grande. Por el contrario, cuando los patrones no son adecuados, se produce una divisi\u00f3n que vuelve a crear unidades m\u00e1s peque\u00f1as. Observo estas transiciones especialmente bajo carga, ya que la promoci\u00f3n y la divisi\u00f3n consumen CPU moment\u00e1neamente y actualizan las listas LRU. Las lecturas secuenciales favorecen la promoci\u00f3n, mientras que las cargas de trabajo muy dispersas tienden a provocar divisiones.<\/p>\n\n<p>La lectura anticipada (readahead) desempe\u00f1a un papel fundamental en este sentido: si se leen por adelantado suficientes datos y estos se consumen posteriormente de forma efectiva, se generan grandes folios casi sin darse cuenta. Por el contrario, si las aplicaciones acceden a los datos en peque\u00f1os pasos impredecibles, la cach\u00e9 sigue siendo granular. Tambi\u00e9n <strong>Writeback<\/strong> Interact\u00faa con p\u00e1ginas grandes: si se escriben simult\u00e1neamente muchas p\u00e1ginas \u00abdirty\u00bb relacionadas entre s\u00ed, el rendimiento y las IOPS pueden mejorar, aunque aumentan los tama\u00f1os de r\u00e1faga. Por ello, tengo en cuenta los par\u00e1metros de ajuste de \u00abdirty\u00bb (p. ej.,. <code>vm.dirty_background_bytes<\/code> y <code>vm.bytes sucios<\/code>), para evitar olas de flush demasiado grandes.<\/p>\n\n<h2>Sistemas de archivos, rutas de E\/S y su influencia<\/h2>\n\n<p>La E\/S con b\u00fafer se beneficia directamente de la cach\u00e9 de p\u00e1ginas, mientras que la E\/S directa (<code>O_DIRECTO<\/code>) lo elude en gran medida. Por lo tanto, en el caso de las bases de datos o las herramientas de copia de seguridad que utilizan deliberadamente Direct I\/O, una cach\u00e9 de p\u00e1ginas transparente tiene menos influencia. En el caso de <code>mmap()<\/code> El efecto depende del patr\u00f3n de acceso: los escaneos p\u00e1gina a p\u00e1gina y en sentido ascendente aprovechan bien los folios m\u00e1s grandes; los saltos aleatorios, no. Con <code>posix_fadvise()<\/code> \u00bfPuedo proporcionar informaci\u00f3n al n\u00facleo (por ejemplo,. <code>SECUENCIAL<\/code>, <code>WILLNEED<\/code>, <code>AL AZAR<\/code>), que controlan la lectura anticipada y el desplazamiento. Estas indicaciones no son garant\u00edas, pero aumentan las posibilidades de que la cach\u00e9 se adapte a mi carga de trabajo.<\/p>\n\n<p>Los sistemas de archivos incorporan sus propias heur\u00edsticas. En algunos sistemas, ext4 y XFS responden de forma muy adecuada a los flujos secuenciales, mientras que los sistemas de archivos de tipo \u00abcopy-on-write\u00bb con deduplicaci\u00f3n o compresi\u00f3n (por ejemplo, \u00e1rboles con muchas instant\u00e1neas) muestran otros perfiles de rendimiento. Por ello, compruebo si la estructura y la fragmentaci\u00f3n del sistema de archivos permiten la existencia de grandes \u00e1reas contiguas. Una operaci\u00f3n de desfragmentaci\u00f3n para datos muy fragmentados puede aportar ventajas cuantificables, pero siempre debe planificarse con precauci\u00f3n y dentro de las ventanas de mantenimiento.<\/p>\n\n<h2>Factores de hardware: arquitectura, NUMA y dispositivos<\/h2>\n\n<p>No todas las arquitecturas utilizan 4 KiB como p\u00e1gina base. En sistemas con p\u00e1ginas base m\u00e1s grandes, la granularidad y el comportamiento de la TLB cambian ya de forma predeterminada. Esto desplaza el rango de utilidad de los folios grandes en la cach\u00e9. Adem\u00e1s, tengo en cuenta las topolog\u00edas NUMA: Las p\u00e1ginas grandes funcionan mejor cuando se encuentran localmente en la CPU que ejecuta el hilo de E\/S o la aplicaci\u00f3n. Por eso, asigno los trabajadores a los nodos, superviso las estad\u00edsticas por NUMA y evito los accesos remotos innecesarios. En Linux, me ayudan las m\u00e9tricas por nodo (<code>\/sys\/devices\/system\/node\/node*\/meminfo<\/code>) y la fijaci\u00f3n del programador, para mantener la localidad.<\/p>\n\n<p>En la p\u00e1gina del dispositivo, compruebo las colas del controlador, la profundidad NVMe y la curva de latencia. Los sitios web de gran tama\u00f1o funcionan bien con un alto rendimiento y una latencia estable, pero son sensibles a los picos de latencia en la cola. Un programador de E\/S que suavice las cargas en r\u00e1fagas puede marcar la diferencia en este caso. Los valores de lectura anticipada (<code>blockdev --getra\/--setra<\/code>) Lo calibro con cuidado para cada dispositivo y cada carga de trabajo.<\/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-page-cache-differences-3942.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Metodolog\u00eda de medici\u00f3n, indicadores clave de rendimiento (KPI) y observabilidad<\/h2>\n\n<p>De antemano, defino unos pocos indicadores, pero muy significativos: tasa de fallos de p\u00e1gina, tasa de aciertos de cach\u00e9, tiempo de CPU por solicitud, carga de la TLB, aciertos de lectura anticipada, percentiles de latencia (P50\/P95\/P99) y accesos fallidos de E\/S. Para obtener una visi\u00f3n general del sistema, utilizo <code>vmstat<\/code>, <code>sar -B<\/code>, <code>iostat<\/code> y <code>pidstat<\/code>, para detectar tendencias. <code>\/proc\/meminfo<\/code> y <code>smaps<\/code> ayudan a desentra\u00f1ar qu\u00e9 hay actualmente en la memoria de trabajo; <code>losa<\/code> muestra la sobrecarga de metadatos. Si es necesario, mido con <code>perfecto<\/code> Errores de TLB y ciclos de CPU bajo carga real, para poner de manifiesto el efecto de las p\u00e1ginas grandes.<\/p>\n\n<p>Para m\u00ed, una prueba consta de tres fases: calentamiento hasta alcanzar una tasa de accesos estable, intervalo de medici\u00f3n bajo carga controlada y enfriamiento para observar la expulsi\u00f3n y la reescritura. Repito las pruebas con el mismo conjunto de datos y cambiando los par\u00e1metros (por ejemplo, lectura anticipada, modo THP <code>siempre\/aconsejar\/nunca<\/code>), para obtener resultados fiables. No paso por alto los valores at\u00edpicos: si el P99 empeora, aunque la media baje, eso suele indicar que la configuraci\u00f3n no se ajusta a mi rango objetivo.<\/p>\n\n<h2>Patrones t\u00edpicos en la pr\u00e1ctica<\/h2>\n\n<p>Las cargas de trabajo de streaming y multimedia leen archivos grandes principalmente de forma secuencial. En este caso, los folios grandes suelen ofrecer ventajas, ya que reducen la presi\u00f3n sobre la TLB y la carga administrativa. Las tareas de copia de seguridad\/restauraci\u00f3n y replicaci\u00f3n con bloques secuenciales largos presentan ventajas similares, especialmente cuando varios procesos leen las mismas \u00e1reas. Los flujos de trabajo de aprendizaje autom\u00e1tico se benefician cuando los conjuntos de datos se agrupan y se almacenan; sin embargo, el muestreo altamente aleatorio a partir de muchos archivos diminutos aten\u00faa este efecto, a menos que se cambie previamente a formatos de contenedor con bloques contiguos.<\/p>\n\n<p>Los entornos de compilaci\u00f3n y de integraci\u00f3n continua (CI) con miles y miles de archivos peque\u00f1os suelen funcionar mejor con una granularidad de 4 KiB. En estos casos, lo que importa es la disponibilidad r\u00e1pida y precisa de los fragmentos m\u00e1s utilizados. En este caso, prefiero invertir en una gran cantidad de RAM para Active(file), una lectura anticipada adecuada por dispositivo y, eventualmente, en cach\u00e9s cercanas a la aplicaci\u00f3n (por ejemplo, cach\u00e9s de dependencias), en lugar de forzar p\u00e1ginas grandes en el n\u00facleo.<\/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_page_cache_tech_4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Control de recursos: Cgroups y protecci\u00f3n del conjunto de trabajo<\/h2>\n\n<p>En entornos multitenant, limito y protejo el espacio de almacenamiento por servicio. Con cgroup v2 se pueden gestionar de forma clara los procesos que consumen mucha memoria de cach\u00e9 de p\u00e1ginas y, si es necesario, a trav\u00e9s de <code>memoria.baja<\/code> proteger, de modo que los conjuntos de trabajo importantes se desplacen con menos frecuencia. <code>memoria.alta<\/code> establece l\u00edmites m\u00e1ximos flexibles, <code>memoria.max<\/code> L\u00edmites estrictos. Observo c\u00f3mo funcionan la equidad y la expulsi\u00f3n cuando varios servicios comparten la misma cach\u00e9 del servidor. Las p\u00e1ginas de gran tama\u00f1o pueden ayudar a aliviar la carga de la CPU, pero tambi\u00e9n pueden provocar bloqueos de expulsi\u00f3n m\u00e1s importantes. Por eso calibro los l\u00edmites de protecci\u00f3n poco a poco y compruebo la din\u00e1mica de la LRU.<\/p>\n\n<h2>Tipos de fallos y medidas correctivas<\/h2>\n\n<p>Cuando se producen con frecuencia situaciones de promoci\u00f3n\/divisi\u00f3n, observo una latencia fluctuante, un uso elevado de la CPU del kernel y una tasa de aciertos variable. Soluciones: ajustar la lectura anticipada, evitar las cascadas de divisi\u00f3n, desentrelazar las cargas de trabajo o reducir la agresividad de las p\u00e1ginas grandes. Si aparecen s\u00edntomas de overfetch (mucho contenido en cach\u00e9, aumento de la presi\u00f3n de intercambio, disminuci\u00f3n de la tasa de aciertos para conjuntos calientes peque\u00f1os), vuelvo a una granularidad m\u00e1s fina o a\u00edslo las lecturas de gran volumen en nodos dedicados. Si los picos de writeback aumentan la latencia de cola, establezco l\u00edmites m\u00e1s estrictos de bytes sucios y suavizo los intervalos de vaciado.<\/p>\n\n<p>Resuelvo el jitter NUMA mediante el \u00abpinning\u00bb de CPU y memoria y una correcta distribuci\u00f3n de los hilos de E\/S. Si se producen fallos de TLB, pero la aplicaci\u00f3n sigue siendo igual de lenta, compruebo la contienda por los bloqueos, los bloqueos del sistema de archivos y el efecto de la compresi\u00f3n y la descifrado en la pila. Una mejora del rendimiento gracias a p\u00e1ginas grandes solo es un verdadero \u00e9xito si se refleja en el punto final de la aplicaci\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_pagecache_schreibtisch4823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Gu\u00eda pr\u00e1ctica para los ex\u00e1menes<\/h2>\n\n<p>Empiezo con una referencia: kernel actual, estado THP (<code>\/sys\/kernel\/mm\/transparent_hugepage\/<\/code>), valores de lectura anticipada, programador de E\/S y estructura de archivos y soportes de datos. A continuaci\u00f3n, defino entre dos y tres hip\u00f3tesis concretas (por ejemplo, \u201eflujos multimedia secuenciales: -10% CPU, P99 m\u00e1s estable\u201c). A continuaci\u00f3n, establezco conjuntos de datos fijos y perfiles de carga que reflejen patrones de tr\u00e1fico realistas. Cada serie de pruebas tiene tiempos de calentamiento id\u00e9nticos, una duraci\u00f3n id\u00e9ntica y un registro de m\u00e9tricas id\u00e9ntico.<\/p>\n\n<p>Solo var\u00edo un par\u00e1metro cada vez: primero el readahead, luego la agresividad de las p\u00e1ginas grandes y, por \u00faltimo, la configuraci\u00f3n de LRU\/Dirty. Despu\u00e9s de cada paso, guardo las m\u00e9tricas y las notas para que las actualizaciones posteriores del n\u00facleo sigan siendo comparables. Solo cuando dos ejecuciones independientes muestran la misma tendencia y las latencias P95\/P99 se mantienen estables, aplico el cambio a un grupo de producci\u00f3n limitado. Siempre se incluye un plan de reversi\u00f3n con umbrales claros (por ejemplo, \u201eP99 &gt; +15% durante 5 min\u201c).<\/p>\n\n<h2>Patrones de acceso y sensibilidad<\/h2>\n\n<p>Los lectores secuenciales que trabajan con archivos de gran tama\u00f1o suelen beneficiarse m\u00e1s de un mayor <strong>P\u00e1ginas<\/strong>. Los accesos aleatorios a muchos archivos peque\u00f1os suelen funcionar mejor con 4 KiB, ya que as\u00ed la cach\u00e9 solo almacena los fragmentos necesarios. Las cargas mixtas requieren mediciones con conjuntos de datos realistas, ya que las pruebas sint\u00e9ticas suelen dar resultados demasiado optimistas. Me fijo en si el \u00aboverfetch\u00bb consume memoria que luego falta en otros lugares. Una peque\u00f1a ganancia en tiempo de CPU no merece la pena si, a cambio, aumenta la presi\u00f3n sobre la LRU y se disparan las latencias.<\/p>\n\n<h2>Escenarios de alojamiento web con muchos archivos peque\u00f1os<\/h2>\n\n<p>El alojamiento compartido t\u00edpico gestiona una gran cantidad de peque\u00f1os scripts, im\u00e1genes y recursos, que la cach\u00e9 de 4 KiB puede almacenar perfectamente en <strong>Mango<\/strong> tiene. Las p\u00e1ginas grandes rara vez aportan valor a\u00f1adido en este caso, ya que los archivos suelen ser inferiores a 2 MiB o se utilizan de forma irregular. En su lugar, invierto en suficiente RAM, una lectura anticipada adecuada por dispositivo y cach\u00e9s a nivel de aplicaci\u00f3n, como OPCache. Adem\u00e1s, compruebo si los recursos est\u00e1ticos se cargan m\u00e1s r\u00e1pido a trav\u00e9s de una cach\u00e9 HTTP que desde el dispositivo de bloques. Solo cuando los perfiles de carga muestran archivos m\u00e1s grandes, abro la puerta a p\u00e1ginas de cach\u00e9 de p\u00e1gina m\u00e1s grandes.<\/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-page-cache-differences-3942.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bases de datos, cach\u00e9s y registros<\/h2>\n\n<p>Las bases de datos en memoria y los montones grandes suelen beneficiarse del THP en el modo an\u00f3nimo <strong>Memoria<\/strong>. En los motores basados en archivos y los flujos de registros con lecturas largas y secuenciales, una cach\u00e9 de p\u00e1ginas transparente tambi\u00e9n puede resultar ventajosa. Compruebo de forma reproducible si disminuyen los errores de p\u00e1gina y si la CPU funciona con mayor fluidez. Al mismo tiempo, observo si el overfetch aumenta el uso de RAM y si var\u00edan los tiempos de arranque en fr\u00edo. Una breve introducci\u00f3n ayuda al principio: utilizo esta gu\u00eda para <a href=\"https:\/\/webhosting.de\/es\/las-huge-pages-transparentes-mejoran-el-rendimiento-de-linux-o-suponen-un-problema-a-la-hora-de-optimizarlo\/\">Evaluar THP<\/a> y evaluar correctamente las interacciones.<\/p>\n\n<h2>Virtualizaci\u00f3n y contenedores<\/h2>\n\n<p>Varias m\u00e1quinas virtuales o contenedores comparten el n\u00facleo del host y, por lo tanto, el <strong>P\u00e1gina<\/strong>-Cach\u00e9. Los binarios y las bibliotecas de uso frecuente se suministran entonces a todas las instancias desde la misma cach\u00e9, lo que ahorra operaciones de E\/S. THP en el sistema invitado puede reducir la carga de la CPU, pero requiere tener en cuenta las zonas NUMA y el overcommit. Realizo mediciones por nodo NUMA para evitar que las p\u00e1ginas de gran tama\u00f1o se desplacen por todo el sistema. Si se produce fluctuaci\u00f3n bajo carga, reduzco la agresividad (madvise) o desactivo THP de forma selectiva hasta que las curvas vuelvan a ser uniformes.<\/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_page_cache_tech_4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comprobar la configuraci\u00f3n y establecerla adecuadamente<\/h2>\n\n<p>Empiezo con una reflexi\u00f3n objetiva <strong>Inventario<\/strong>: \u00bfQu\u00e9 versi\u00f3n del kernel, qu\u00e9 valores predeterminados, qu\u00e9 opciones de montaje, qu\u00e9 valores de lectura anticipada? Compruebo el estado de THP en \/sys\/kernel\/mm\/transparent_hugepage\/ (p. ej., enabled, defrag, khugepaged). Para el comportamiento de la cach\u00e9 de p\u00e1ginas, consulto \/proc\/meminfo, las estad\u00edsticas por nodo y el readahead por bloques. Nunca aplico los cambios a ciegas, sino que primero los pruebo en un entorno de staging con datos reales. Solo despu\u00e9s de eso incorporo las configuraciones estables al entorno de producci\u00f3n.<\/p>\n\n<h2>Ajuste fino: lectura anticipada, expulsi\u00f3n y supervisi\u00f3n<\/h2>\n\n<p>Las p\u00e1ginas grandes solo funcionan si el readahead, el programador de E\/S y la LRU funcionan bien <strong>juntos<\/strong>probar. Analizo la tasa de errores de p\u00e1gina, las faltas de acierto, el tiempo de CPU y los posibles picos de latencia al dividir o fusionar p\u00e1ginas grandes. En situaciones de carga elevada, me interesa saber con qu\u00e9 rapidez la cach\u00e9 desplaza las p\u00e1ginas antiguas y si se pierden archivos importantes. Un buen punto de partida para analizar el desplazamiento es este art\u00edculo sobre <a href=\"https:\/\/webhosting.de\/es\/servidor-pagina-cache-desalojo-linux-memoria-impresion-optimizacion-insight\/\">Desahucio bajo la presi\u00f3n de la memoria<\/a>, donde se explica el patr\u00f3n t\u00edpico. A continuaci\u00f3n, ajusto con cuidado el readahead, las opciones del sistema de archivos y, si procede, el uso de p\u00e1ginas grandes.<\/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_pagecache_schreibtisch4823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Lista de comprobaci\u00f3n para la consulta sin mitos<\/h2>\n\n<p>Empiezo con unos objetivos claros: reducir el tiempo de CPU, conseguir una latencia m\u00e1s estable y ajustar <strong>Tasa de aciertos<\/strong> en la cach\u00e9 de p\u00e1ginas. A continuaci\u00f3n, defino puntos de medici\u00f3n y selecciono cargas de trabajo reales que muestren picos y cargas mixtas. Despu\u00e9s, pruebo p\u00e1ginas cada vez m\u00e1s grandes, primero en el entorno de prueba y luego, de forma limitada, en producci\u00f3n. Tengo preparados planes de reversi\u00f3n por si se producen overfetch, fragmentaci\u00f3n o jitter. Por \u00faltimo, documento los efectos para que la configuraci\u00f3n siga siendo reproducible y se puedan evaluar las futuras actualizaciones del kernel.<\/p>\n\n<h2>Brevemente resumido<\/h2>\n\n<p>La cach\u00e9 cl\u00e1sica de 4 KiB sigue siendo la opci\u00f3n m\u00e1s fiable para muchas aplicaciones <strong>Base<\/strong>, ya que gestiona la RAM de forma granular y eficiente. Una cach\u00e9 de p\u00e1ginas transparente reduce la carga de la TLB y los metadatos cuando se leen archivos grandes de forma secuencial. THP gestiona las \u00e1reas de memoria an\u00f3nimas y puede ser \u00fatil para montones grandes, aunque requiere precauci\u00f3n debido a posibles picos de latencia. Tomo la decisi\u00f3n bas\u00e1ndome en los datos: medir, comparar y, a continuaci\u00f3n, implementar. Quien proceda as\u00ed conseguir\u00e1 tiempos de respuesta predecibles, un uso racional de la RAM y una CPU notablemente m\u00e1s tranquila.<\/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-page-cache-setup-5726.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>","protected":false},"excerpt":{"rendered":"<p>Descubre c\u00f3mo funciona la cach\u00e9 de p\u00e1ginas transparente de Linux, en qu\u00e9 se diferencia de la cach\u00e9 de p\u00e1ginas cl\u00e1sica y c\u00f3mo puedes optimizar la gesti\u00f3n de la memoria para obtener el m\u00e1ximo rendimiento. Tema central: cach\u00e9 de p\u00e1ginas transparente.<\/p>","protected":false},"author":1,"featured_media":21019,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21026","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":"118","_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":"transparent page cache","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":"21019","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21026","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=21026"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21026\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/21019"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=21026"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=21026"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=21026"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}