{"id":20540,"date":"2026-08-11T11:56:13","date_gmt":"2026-08-11T09:56:13","guid":{"rendered":"https:\/\/webhosting.de\/linux-page-cache-performance-booster\/"},"modified":"2026-08-11T11:56:13","modified_gmt":"2026-08-11T09:56:13","slug":"optimizador-del-rendimiento-de-la-cache-de-paginas-de-linux","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/linux-page-cache-performance-booster\/","title":{"rendered":"Entender la cach\u00e9 de p\u00e1ginas de Linux: mayor rendimiento gracias a la cach\u00e9"},"content":{"rendered":"<p><strong>P\u00e1gina de Linux<\/strong> Entiendo la cach\u00e9 como una herramienta directa para acelerar el acceso a los archivos, ya que permite realizar lecturas repetidas desde la RAM en lugar de desde un almacenamiento m\u00e1s lento. Mostrar\u00e9 concretamente c\u00f3mo el n\u00facleo reduce as\u00ed las latencias, acelera cargas de trabajo como servidores web, bases de datos y WordPress, y c\u00f3mo aprovecho este efecto con medios sencillos.<\/p>\n\n<h2>Puntos centrales<\/h2>\n\n<p>Las siguientes ideas clave me ayudan a... <strong>Cach\u00e9 de p\u00e1gina<\/strong> evaluarlos y aprovecharlos de forma espec\u00edfica.<\/p>\n<ul>\n  <li><strong>Cach\u00e9 de RAM<\/strong>: Los datos de los archivos se almacenan en la memoria y aceleran el acceso a ellos.<\/li>\n  <li><strong>Reversi\u00f3n<\/strong>: Las operaciones de escritura se agrupan de forma m\u00e1s eficiente en \u201ep\u00e1ginas sucias\u201c.<\/li>\n  <li><strong>Transparencia<\/strong>: Las aplicaciones se benefician de ello sin necesidad de modificar el c\u00f3digo.<\/li>\n  <li><strong>Din\u00e1mica<\/strong>: La cach\u00e9 libera memoria cuando es necesario.<\/li>\n  <li><strong>Cargas de trabajo<\/strong>: Web, bases de datos, CI\/CD y registros mejoran notablemente.<\/li>\n<\/ul>\n\n<h2>\u00bfQu\u00e9 es la cach\u00e9 de p\u00e1ginas de Linux?<\/h2>\n\n<p>Entiendo el <strong>Cach\u00e9 de p\u00e1gina<\/strong> como \u00e1rea de memoria en la RAM en la que el n\u00facleo almacena bloques de archivos tan pronto como los procesos, a trav\u00e9s de <code>read()<\/code>, <code>write()<\/code> o <code>mmap()<\/code> acceder a los archivos. Cada vez que se produce un acceso, el n\u00facleo comprueba primero la cach\u00e9 y, si los datos ya est\u00e1n disponibles, los entrega inmediatamente desde la memoria, lo que reduce de forma apreciable el tiempo de respuesta. Si los datos no se encuentran en la cach\u00e9, el n\u00facleo los carga desde el soporte de datos, los almacena all\u00ed y los pone a disposici\u00f3n del proceso, lo que permite una recuperaci\u00f3n r\u00e1pida en el siguiente acceso. Este mecanismo est\u00e1 estrechamente relacionado con el sistema de archivos virtual y funciona de forma transparente para las aplicaciones, lo que hace que su uso sea universal. De este funcionamiento se deriva un principio sencillo: utilizo la RAM libre como <strong>Superficie de la cach\u00e9<\/strong> en lugar de dejarlo sin usar.<\/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\/linux-page-cache-performance-5830.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Por qu\u00e9 la cach\u00e9 de p\u00e1ginas acelera notablemente el rendimiento<\/h2>\n\n<p>El efecto m\u00e1s notable se debe a que yo <strong>E\/S de disco<\/strong> se reduce dr\u00e1sticamente en cuanto los datos recurrentes se almacenan en la cach\u00e9 y ya no es necesario volver a leerlos del soporte de almacenamiento. Las operaciones de lectura se realizan entonces desde la RAM, lo que reduce considerablemente las latencias y las colas en los controladores. Las rutas de escritura tambi\u00e9n se benefician, ya que el n\u00facleo marca los cambios como \u201ep\u00e1ginas sucias\u201c, los agrupa temporalmente y los escribe posteriormente de forma eficiente en el soporte de almacenamiento. De este modo, desaparecen muchos peque\u00f1os accesos individuales que sobrecargar\u00edan el almacenamiento, en favor de un n\u00famero menor de operaciones m\u00e1s grandes. En resumen, tras una breve fase de calentamiento, el sistema parece m\u00e1s r\u00e1pido porque hay m\u00e1s datos de trabajo en la <strong>Memoria<\/strong> quedan.<\/p>\n\n<h2>Leer, escribir, \u00abDirty Pages\u00bb: as\u00ed es como funciona<\/h2>\n\n<p>Un acceso de lectura siempre comienza con una comprobaci\u00f3n de la cach\u00e9, lo que me permite obtener aciertos sin tiempo de espera y que los fallos solo supongan un coste \u00fanico. Al escribir, el contenido modificado se almacena primero en la RAM y pasa a un estado de espera como \u201esucio\u201c hasta que el n\u00facleo lo transfiere de forma agrupada al soporte de datos. Si lo deseo, puedo forzar el almacenamiento permanente con <code>fsync()<\/code>, lo que sigue siendo importante cuando se trata de datos <strong>Coherencia<\/strong> necesito de inmediato. Esta ruta de \u00abwrite-back\u00bb aumenta la eficiencia de las aplicaciones que manejan muchos archivos peque\u00f1os, como c\u00f3digo PHP, archivos de configuraci\u00f3n o recursos. Al mismo tiempo, tengo en cuenta que el \u00abwrite-back\u00bb mejora el rendimiento, pero que existe un breve intervalo de tiempo en el que a\u00fan no todo est\u00e1 guardado f\u00edsicamente.<\/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_3892.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>La RAM libre es cach\u00e9, no supone ninguna p\u00e9rdida<\/h2>\n\n<p>Muchos ven con escepticismo la memoria \u201eocupada\u201c, pero yo interpreto correctamente el valor considerando la proporci\u00f3n de \u201ebuff\/cache\u201c como un indicador significativo <strong>memoria intermedia<\/strong> Valores. El n\u00facleo utiliza activamente la RAM no utilizada, la devuelve a los procesos a la velocidad del rayo cuando es necesario y controla el equilibrio mediante mecanismos de recuperaci\u00f3n. Esta din\u00e1mica garantiza que mi sistema responda con rapidez, siempre que haya suficiente conjunto de trabajo en la cach\u00e9. Si aumenta la demanda de una aplicaci\u00f3n, el n\u00facleo desplaza las p\u00e1ginas antiguas de la cach\u00e9 y libera espacio sin que yo tenga que intervenir manualmente. Cuando entro en fases de alta carga, lo observo prestando especial atenci\u00f3n a <a href=\"https:\/\/webhosting.de\/es\/presion-de-memoria-kernel-de-linux-sistemas-de-alojamiento-optimizacion-ram\/\">Presi\u00f3n del acumulador<\/a>, para evaluar correctamente la situaci\u00f3n y clasificar los cuellos de botella.<\/p>\n\n<h2>Cargas de trabajo que se benefician enormemente<\/h2>\n\n<p>Considero que las mayores ventajas se dan en aquellos casos en los que los datos se repiten con frecuencia y se producen muchos peque\u00f1os accesos, lo que el <strong>Cache<\/strong> simplificado. Algunos ejemplos cl\u00e1sicos son los servidores web con archivos PHP y HTML de uso frecuente, as\u00ed como las instalaciones de WordPress con temas, plugins, archivos multimedia y configuraciones recurrentes. Las bases de datos se benefician de las consultas repetidas a nivel del sistema de archivos, siempre que no eludan deliberadamente la cach\u00e9 de p\u00e1ginas. Los sistemas de CI\/CD con artefactos de compilaci\u00f3n, as\u00ed como las herramientas que manejan muchos archivos peque\u00f1os, tambi\u00e9n se aceleran notablemente. Incluso los an\u00e1lisis de registros, que se leen de forma secuencial, obtienen una ventaja gracias a los b\u00faferes de RAM, ya que el n\u00facleo almacena los patrones de acceso y los proporciona m\u00e1s r\u00e1pidamente.<\/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-performance-3829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Seguimiento y medici\u00f3n: as\u00ed es como eval\u00fao los efectos de la cach\u00e9<\/h2>\n\n<p>Para empezar, compruebo con <code>libre -h<\/code>, cu\u00e1l es el tama\u00f1o de \u201ebuff\/cache\u201c y c\u00f3mo <strong>m\u00e1s ocupado<\/strong> La memoria se ha ido desarrollando a lo largo del tiempo. Un vistazo a <code>\/proc\/meminfo<\/code> me muestra indicadores como <code>En cach\u00e9<\/code>, <code>Sucio<\/code> y <code>Writeback<\/code>, que proporcionan informaci\u00f3n sobre los accesos de lectura y las operaciones de escritura pendientes. Con <code>iostat -x 1<\/code> o <code>pidstat -d 1<\/code> Me doy cuenta de si la carga de E\/S f\u00edsica disminuye en cuanto mi cach\u00e9 se ha calentado. Herramientas como <code>perfecto<\/code> o <code>cco<\/code>Los scripts basados en esto ayudan a profundizar en el an\u00e1lisis, pero rara vez son necesarios en el d\u00eda a d\u00eda cuando se observan patrones claros. Adem\u00e1s, compruebo, mediante accesos repetidos a los archivos, si la segunda ejecuci\u00f3n es significativamente m\u00e1s r\u00e1pida, lo que demuestra el efecto del <strong>Cach\u00e9s<\/strong> Confirmado.<\/p>\n\n<h2>Ajuste: par\u00e1metros y valores predeterminados recomendados<\/h2>\n\n<p>Solo ajusto lo que entiendo y, a la hora de optimizar la cach\u00e9, empiezo con unos pocos ajustes f\u00e1ciles de entender <strong>Tornillos de ajuste<\/strong>. Los par\u00e1metros vm.dirty controlan a partir de qu\u00e9 momento se transfieren las operaciones de escritura de la RAM al soporte de almacenamiento y con qu\u00e9 intensidad se lleva a cabo este proceso. <code>vm.vfs_cache_pressure<\/code> Determina en qu\u00e9 medida el n\u00facleo desplaza las cach\u00e9s de Dentry e inodo, lo que influye directamente en las operaciones del sistema de archivos. Los valores de lectura anticipada a nivel de dispositivo de bloques pueden mejorar el rendimiento de la lectura secuencial cuando las cargas de trabajo se benefician de ello. Documento cada paso, realizo pruebas bajo carga y, si es necesario, vuelvo a los valores iniciales en caso de que no se observe ninguna mejora.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Par\u00e1metros<\/strong><\/th>\n      <th><strong>Est\u00e1ndar<\/strong><\/th>\n      <th><strong>Efecto<\/strong><\/th>\n      <th><strong>\u00bfCu\u00e1ndo cambiar?<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>vm.dirty_background_ratio<\/td>\n      <td>10%<\/td>\n      <td>Inicio de la fase de reescritura as\u00edncrona<\/td>\n      <td>En el caso de muchas operaciones de escritura peque\u00f1as, realizar el flushing antes<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio<\/td>\n      <td>20%<\/td>\n      <td>Porcentaje m\u00e1ximo de \u201edirty\u201c en la RAM<\/td>\n      <td>En caso de picos de carga, aumentar el margen de seguridad<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_expire_centisecs<\/td>\n      <td>3000<\/td>\n      <td>Tiempo \u201edirty\u201c hasta el flush (en 1\/100 s)<\/td>\n      <td>En el caso de los objetivos de latencia, ajusta un valor m\u00e1s bajo<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_writeback_centisegundos<\/td>\n      <td>500<\/td>\n      <td>Intervalo para la reescritura en segundo plano<\/td>\n      <td>Si el almacenamiento va lento, aumenta un poco la velocidad<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.vfs_cache_pressure<\/td>\n      <td>100<\/td>\n      <td>Necesidad de liberar dentries\/inodos<\/td>\n      <td>En muchas operaciones con archivos, se reduce<\/td>\n    <\/tr>\n    <tr>\n      <td>Lectura anticipada por bloques<\/td>\n      <td>dependiendo del dispositivo<\/td>\n      <td>Vista previa de lectura secuencial<\/td>\n      <td>Aumentar en lecturas en streaming<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Para conocer con m\u00e1s detalle los procesos de recuperaci\u00f3n y almacenamiento, merece la pena echar un vistazo a <a href=\"https:\/\/webhosting.de\/es\/servidor-pagina-cache-desalojo-linux-memoria-impresion-optimizacion-insight\/\">Eliminaci\u00f3n de la cach\u00e9 de p\u00e1ginas<\/a>, para evaluar de forma fundamentada la propia configuraci\u00f3n. Siempre aplico los cambios de forma gradual, realizo mediciones y documento los efectos con claridad, para que cada <strong>Personalizaci\u00f3n<\/strong> siga siendo comprensible.<\/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\/LinuxCachePerformance5678.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cach\u00e9 de p\u00e1ginas y bases de datos: cu\u00e1ndo conviene evitarlas<\/h2>\n\n<p>Algunas bases de datos recurren deliberadamente a <strong>E\/S directa<\/strong> para evitar el almacenamiento duplicado en la memoria intermedia y utilizar sus propias cach\u00e9s. En estos casos, trabajo con los par\u00e1metros internos de la base de datos y recurro menos a la cach\u00e9 de p\u00e1ginas de Linux. Si un motor accede con frecuencia a datos nuevos o a vol\u00famenes de trabajo muy grandes, merece la pena utilizar el modelo de derivaci\u00f3n para que el consumo de memoria sea m\u00e1s predecible. Por el contrario, si la actividad se centra en lecturas repetidas de archivos procedentes de las mismas tablas o \u00edndices, la cach\u00e9 del sistema de archivos sigue siendo \u00fatil. Tomo la decisi\u00f3n en funci\u00f3n del patr\u00f3n de acceso real, no bas\u00e1ndome en una regla general, para que la <strong>Actuaci\u00f3n<\/strong> realmente aumenta.<\/p>\n\n<h2>Desalojo, recuperaci\u00f3n y presi\u00f3n de memoria<\/h2>\n\n<p>Cuando la carga es elevada, el n\u00facleo clasifica las p\u00e1ginas en activas e inactivas <strong>Listas de LRU<\/strong> y elimina gradualmente los candidatos de la cach\u00e9. Este proceso de recuperaci\u00f3n responde a la presi\u00f3n derivada del aumento de la demanda de procesos, los l\u00edmites de cgroup o los tiempos de espera de E\/S. Si mi sistema de monitorizaci\u00f3n detecta un aumento de las expulsiones y, al mismo tiempo, un incremento de la carga de E\/S, deduzco que el conjunto de datos de trabajo es mayor que la RAM disponible. En tales situaciones, eval\u00fao si debo aislar las cargas de trabajo, modificar las estrategias de almacenamiento en cach\u00e9 o ampliar la memoria. Para comprender las reglas de desalojo, me resulta \u00fatil una gu\u00eda estructurada sobre <a href=\"https:\/\/webhosting.de\/es\/presion-de-memoria-kernel-de-linux-sistemas-de-alojamiento-optimizacion-ram\/\">Presi\u00f3n del acumulador<\/a>, para interpretar correctamente los s\u00edntomas y planificar las medidas a adoptar.<\/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_cache_performance_8372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pr\u00e1ctica: comprobaciones r\u00e1pidas y \u00f3rdenes<\/h2>\n\n<p>Para dar una primera impresi\u00f3n, voy a empezar con <code>libre -h<\/code> y lee la parte <strong>buff\/cach\u00e9<\/strong>, antes de profundizar m\u00e1s. A continuaci\u00f3n, comparar\u00e9 dos ejecuciones de un escaneo de archivos, por ejemplo, con <code>encontrar<\/code> o una prueba de rendimiento, y observa la diferencia de tiempo entre el arranque en fr\u00edo y el arranque en caliente. <code>grep -E \"Cached|Dirty|Writeback\" \/proc\/meminfo<\/code> Me muestra cu\u00e1nto hay en la cach\u00e9 y qu\u00e9 queda por escribir. <code>iostat -xz 1<\/code> revela el nivel de ocupaci\u00f3n de los dispositivos y si la cola se reduce en cuanto entra en acci\u00f3n la cach\u00e9. Quien desee conocer m\u00e1s detalles sobre los fundamentos del almacenamiento en cach\u00e9, encontrar\u00e1 en la descripci\u00f3n general de <a href=\"https:\/\/webhosting.de\/es\/sistema-de-archivos-almacenamiento-en-cache-linux-cache-de-pagina-cacheboost\/\">Almacenamiento en cach\u00e9 del sistema de archivos<\/a> Una gu\u00eda introductoria f\u00e1cil de entender que explica la interacci\u00f3n entre el VFS y el b\u00fafer de la RAM.<\/p>\n\n<h2>Aclarar malentendidos habituales<\/h2>\n\n<p>\u201eLa memoria RAM est\u00e1 llena, el servidor tiene un problema\u201c, oigo decir a menudo, pero el <strong>Cache<\/strong> Esta es la respuesta, no la causa. Linux libera memoria de forma flexible cuando las aplicaciones la ocupan, y la vuelve a ocupar en cuanto se almacenan nuevos datos temporalmente. El vaciado manual mediante <code>echo 3 &gt; \/proc\/sys\/vm\/drop_caches<\/code> rara vez aporta un beneficio duradero y distorsiona las mediciones. Es m\u00e1s sensato identificar los verdaderos puntos cr\u00edticos y aliviar la carga en las rutas de E\/S en esos puntos. Adem\u00e1s, distingo entre la cach\u00e9 de p\u00e1ginas y las cach\u00e9s \u00abslab\u00bb para dentries\/inodes, para no tener dos diferentes <strong>Mecanismos<\/strong> lo echo en una olla.<\/p>\n\n<h2>Opciones de montaje y matices del sistema de archivos<\/h2>\n\n<p>Tengo en cuenta que las opciones del sistema de archivos y de montaje influyen considerablemente en la eficiencia de la cach\u00e9 de p\u00e1ginas. <strong>atime<\/strong>-Las actualizaciones generan escrituras adicionales; con <em>relatime<\/em> (hoy en d\u00eda es lo habitual) las reduzco, <em>noatime<\/em> Ahorro a\u00fan m\u00e1s si nunca tengo que depender de los horarios de acceso. <strong>sincronizar<\/strong> y <strong>dirsync<\/strong> imponen una persistencia inmediata y anulan las ventajas del \u00abwrite-back\u00bb; son adecuadas para metadatos en los que la latencia es cr\u00edtica, pero, en los dem\u00e1s casos, prefiero evitarlas. Modos de registro en diario (p. ej., en ext4 <em>datos=ordenados<\/em> vs. <em>writeback<\/em>) influyen en si los datos \u00fatiles se almacenan en el soporte antes o despu\u00e9s de los metadatos; yo prefiero la seguridad al rendimiento aparente. XFS y btrfs se comportan de forma diferente en lo que respecta a los metadatos y CoW: CoW, la compresi\u00f3n o la deduplicaci\u00f3n ahorran E\/S, pero pueden suponer un coste para la CPU. Por eso mido las cargas de trabajo de forma realista y decido si las opciones de montaje se ajustan al patr\u00f3n de acceso.<\/p>\n\n<h2>Contenedores, m\u00e1quinas virtuales y cach\u00e9s duplicadas<\/h2>\n\n<p>En los contenedores, todos los procesos comparten el mismo n\u00facleo y, por lo tanto, tambi\u00e9n la misma cach\u00e9 de p\u00e1ginas. Esto facilita el uso compartido de archivos de uso frecuente (por ejemplo, bibliotecas), pero los l\u00edmites estrictos de los cgroups (<em>memoria.max<\/em>) pueden desplazar las p\u00e1ginas en cach\u00e9 antes de tiempo. Preveo un margen de seguridad para cada servicio y utilizo <em>memoria.baja<\/em>, para proteger un poco las cach\u00e9s importantes. En las m\u00e1quinas virtuales existen <strong>dos<\/strong> Cach\u00e9s: en el invitado y, en su caso, en el host (en el caso de copias de seguridad de archivos). Esto provoca un almacenamiento en b\u00fafer duplicado. Si utilizo dispositivos sin formato (Raw) o almacenamiento directo (Direct-Storage), evito la cach\u00e9 del host, pero pierdo sus ventajas. El ballooning y el overcommit influyen en la recuperaci\u00f3n de memoria en el invitado: observo si el ballooning constante provoca un thrashing de la cach\u00e9 y ajusto los recursos o el dimensionamiento. En el caso del almacenamiento en contenedores (OverlayFS), precaliento de forma selectiva las capas m\u00e1s utilizadas para que las implementaciones no se inicien en fr\u00edo.<\/p>\n\n<h2>NUMA, cgroups y aislamiento<\/h2>\n\n<p>En los sistemas NUMA, el n\u00facleo gestiona listas LRU por nodo. Si los subprocesos acceden principalmente a memoria local, las coincidencias en la cach\u00e9 de p\u00e1ginas <strong>numa-nah<\/strong> y reducimos la latencia. Mediante la afinidad de CPU y memoria, me aseguro de que una aplicaci\u00f3n y sus datos est\u00e9n situados cerca unos de otros. A trav\u00e9s de <strong>memcg<\/strong> (cgroups v2) la cach\u00e9 de p\u00e1ginas se asigna a un grupo; con <em>memoria.alta<\/em> activar\u00e9 una recuperaci\u00f3n controlada con <em>memoria.max<\/em> establezco l\u00edmites estrictos y con <em>memoria.baja<\/em> Doy prioridad a los servicios importantes. Estas herramientas ayudan a evitar que un trabajo por lotes que genere mucho ruido vac\u00ede la cach\u00e9 de un servicio web sensible a la latencia. El aislamiento permite planificar mejor, pero busco un equilibrio para que no se creen demasiadas cach\u00e9s peque\u00f1as que, por separado, obtengan muy pocos aciertos.<\/p>\n\n<h2>SSD, HDD y la pr\u00e1ctica de la lectura anticipada<\/h2>\n\n<p>El readahead es una ventaja para los patrones secuenciales, pero a menudo solo supone un lastre para los accesos aleatorios. En los discos duros (HDD), suelo aumentar el readahead para acelerar los escaneos lineales. En los SSD NVMe r\u00e1pidos, el beneficio es menor; un readahead excesivo desperdicia RAM y empeora los aciertos de cach\u00e9, ya que las p\u00e1ginas no utilizadas desplazan a otras. Ajusto la lectura anticipada para cada dispositivo y compruebo, mediante pruebas repetidas, si mejora el rendimiento o las latencias. Adem\u00e1s, tengo en cuenta el programador de E\/S: para NVMe lo habitual es \u201enone\u201c\/\u201emq-deadline\u201c, mientras que los discos duros (HDD) pueden beneficiarse de la programaci\u00f3n por plazo (deadline). La cach\u00e9 de p\u00e1ginas suaviza los perfiles de E\/S, pero la capa de bloques debe adaptarse a ello. El objetivo sigue siendo que la cach\u00e9 contenga principalmente datos \u00fatiles y reutilizados, y no solo bytes recuperados por adelantado.<\/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-performance-4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Arranques en fr\u00edo, precalentamiento e implementaciones<\/h2>\n\n<p>Cada cach\u00e9 necesita una fase de calentamiento. Tras un reinicio o una implementaci\u00f3n, leo de forma selectiva los \u201ehotsets\u201c, por ejemplo, recorriendo secuencialmente los directorios importantes. Esto reduce notablemente el \u00abminuto en fr\u00edo\u00bb tras las implementaciones. En estrategias de implementaci\u00f3n progresiva, mantengo al menos una instancia \u00abcaliente\u00bb en l\u00ednea para que el servicio en su conjunto responda r\u00e1pidamente mientras las nuevas instancias llenan su cach\u00e9. Evito los cambios masivos en el \u00e1rbol de archivos (por ejemplo, cambios de rutas), ya que esto enfr\u00eda los dentries\/inodos. En su lugar, trabajo con cambios at\u00f3micos de enlaces simb\u00f3licos o estrategias de \u00abcopia al escribir\u00bb, en las que el contenido de los archivos y las rutas permanecen en gran medida estables. De este modo, no solo se mantiene la eficacia de la cach\u00e9 de p\u00e1ginas, sino que tambi\u00e9n conservan su eficacia las cach\u00e9s de metadatos.<\/p>\n\n<h2>Par\u00e1metros de medici\u00f3n en profundidad<\/h2>\n\n<p>Adem\u00e1s de <code>\/proc\/meminfo<\/code> Para realizar diagn\u00f3sticos precisos, echo un vistazo a <code>\/proc\/vmstat<\/code>: Contadores como <em>pgfault<\/em> y <em>pgmajfault<\/em> distinguen entre fallos de p\u00e1gina leves y graves, <em>nr_active_file<\/em>\/<em>nr_inactive_file<\/em> muestran el tama\u00f1o del conjunto de trabajo basado en archivos, y <em>workingset_refault<\/em> Ayuda a detectar el \u00abthrashing\u00bb. Si aumentan los \u00abrefaults\u00bb mientras la tasa de E\/S del dispositivo se mantiene alta, el conjunto de trabajo no cabe en la RAM. Realizo la prueba con dos ejecuciones de la misma carga de trabajo: la segunda pasada deber\u00eda ser notablemente m\u00e1s r\u00e1pida si la cach\u00e9 funciona correctamente. Para que las pruebas de arranque en fr\u00edo sean reproducibles, vac\u00edo las cach\u00e9s exclusivamente en el entorno de laboratorio y lo documento con precisi\u00f3n, para no falsear las mediciones de producci\u00f3n. Para m\u00ed es importante no sobreinterpretar un \u00fanico indicador, sino identificar patrones a lo largo de series temporales.<\/p>\n\n<h2>C\u00f3mo evitar el swap, el \u00abswappiness\u00bb y el \u00abthrashing\u00bb<\/h2>\n\n<p>Cuando se ve sometido a presi\u00f3n, Linux vac\u00eda primero la cach\u00e9 de p\u00e1ginas antes de recurrir a las p\u00e1ginas an\u00f3nimas, siempre que ello resulte conveniente. Si la memoria RAM para los procesos empieza a escasear y no hay suficientes p\u00e1ginas an\u00f3nimas libres, el sistema comienza a utilizar el swap. Una <strong>demasiado baja<\/strong> La \u00abswappiness\u00bb puede provocar que se mantenga de forma agresiva memoria an\u00f3nima importante (heaps\/stacks) y que, en su lugar, se desplace p\u00e1ginas de cach\u00e9 \u00fatiles, lo que aumenta las operaciones de E\/S. Una <strong>demasiado alta<\/strong> Por el contrario, el uso excesivo del swap provoca una externalizaci\u00f3n prematura y picos de latencia. Elijo valores moderados, mido y observo: el objetivo es que mi \u00abhotset\u00bb permanezca en la RAM y que solo los datos \u00abfr\u00edos\u00bb, que se utilizan con poca frecuencia, se trasladen al swap, nunca los \u00abcalientes\u00bb.<\/p>\n\n<h2>Seguridad y durabilidad: los datos en el soporte<\/h2>\n\n<p>La funci\u00f3n \u00abWrite-back\u00bb mejora el rendimiento, pero crea un breve intervalo en el que los cambios solo se almacenan en la RAM. Para los datos que deben conservarse de forma inmediata, utilizo <code>fsync()<\/code> o <code>fdatasync()<\/code>. Adem\u00e1s, conf\u00edo en los valores predeterminados seguros, como las barreras de escritura y el registro en diario; evito las opciones arriesgadas que desactivan dichas barreras. A nivel de almacenamiento, presto atenci\u00f3n a las cach\u00e9s de los controladores: las pol\u00edticas de escritura diferida con bater\u00eda o condensador son r\u00e1pidas y seguras, mientras que las cach\u00e9s inseguras sin protecci\u00f3n resultan delicadas. A nivel de todo el sistema, se impone <code>sincronizar<\/code> El borrado de todos los datos: una herramienta rudimentaria que utilizo de forma consciente y en contadas ocasiones. As\u00ed es como combino la velocidad que ofrece la cach\u00e9 de p\u00e1ginas con una persistencia limpia all\u00ed donde resulta fundamental para el negocio.<\/p>\n\n<h2>WordPress y las pilas web: consejos pr\u00e1cticos<\/h2>\n\n<p>En la pila web se acumulan las cach\u00e9s: la cach\u00e9 de p\u00e1ginas de Linux acelera los recursos est\u00e1ticos, los archivos PHP y las configuraciones, mientras que una cach\u00e9 de c\u00f3digo OP de PHP mantiene en memoria la ruta de ejecuci\u00f3n y el c\u00f3digo de bytes. Me aseguro de que las implementaciones no modifiquen constantemente la ruta del c\u00f3digo y reduzco los accesos a los archivos agrupando los recursos. Una capa de cach\u00e9 de objetos persistente reduce las operaciones de E\/S de la base de datos, lo que permite que la cach\u00e9 del sistema de archivos gestione los archivos m\u00e1s solicitados de forma a\u00fan m\u00e1s eficaz. Siempre que es posible, no guardo las sesiones y los datos transitorios en el disco local, sino en cach\u00e9s de memoria o de red, para que la cach\u00e9 de p\u00e1ginas pueda aprovechar al m\u00e1ximo su potencial con el resto de archivos de lectura frecuente. Resultado: menos E\/S f\u00edsica, respuestas m\u00e1s r\u00e1pidas y latencias m\u00e1s estables.<\/p>\n\n<h2>Brevemente resumido<\/h2>\n\n<p>La cach\u00e9 de p\u00e1ginas de Linux me proporciona respuestas r\u00e1pidas a las solicitudes de archivos <strong>RAM<\/strong> y reduce considerablemente los costosos accesos al soporte de datos. Las lecturas en paralelo aceleran las aplicaciones, mientras que la escritura diferida agrupa numerosas escrituras individuales y aumenta la eficiencia. La memoria libre no queda inactiva, sino que funciona como cach\u00e9 para garantizar una plataforma con gran capacidad de respuesta. Con puntos de medici\u00f3n como <code>libre -h<\/code>, <code>\/proc\/meminfo<\/code> y <code>iostat<\/code> me doy cuenta del efecto antes de tener en cuenta par\u00e1metros como <code>vm.dirty_ratio<\/code> o <code>vm.vfs_cache_pressure<\/code> Ve. Quien conozca las cargas de trabajo, pruebe los cambios de forma controlada y utilice la cach\u00e9 de forma selectiva, conseguir\u00e1 una mejora notable en <strong>Actuaci\u00f3n<\/strong> sin modificar el c\u00f3digo.<\/p>","protected":false},"excerpt":{"rendered":"<p>La cach\u00e9 de p\u00e1ginas de Linux utiliza la memoria RAM como cach\u00e9, lo que mejora el rendimiento del servidor en el alojamiento web, WordPress y el acceso a archivos.<\/p>","protected":false},"author":1,"featured_media":20533,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20540","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":"174","_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":null,"_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":"Linux Page","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":"20533","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20540","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=20540"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20540\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/20533"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=20540"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=20540"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=20540"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}