{"id":16421,"date":"2025-12-31T18:20:15","date_gmt":"2025-12-31T17:20:15","guid":{"rendered":"https:\/\/webhosting.de\/filesystem-caching-linux-page-cache-cacheboost\/"},"modified":"2025-12-31T18:20:15","modified_gmt":"2025-12-31T17:20:15","slug":"sistema-de-archivos-almacenamiento-en-cache-linux-cache-de-pagina-cacheboost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/filesystem-caching-linux-page-cache-cacheboost\/","title":{"rendered":"Almacenamiento en cach\u00e9 del sistema de archivos en el alojamiento Linux: comprender correctamente la cach\u00e9 de p\u00e1gina"},"content":{"rendered":"<p>La cach\u00e9 de p\u00e1gina de Linux determina la velocidad a la que las cargas de trabajo de alojamiento leen y escriben archivos, ya que mantiene los datos de uso frecuente en la RAM y evita as\u00ed costosos accesos al dispositivo. Te muestro c\u00f3mo hacerlo. <strong>Sistema de archivos<\/strong> El almacenamiento en cach\u00e9 en el alojamiento Linux funciona, qu\u00e9 indicadores son importantes y c\u00f3mo puedo controlar la cach\u00e9 para el uso diario sin que <strong>Servidor<\/strong>-Aumentar la carga.<\/p>\n\n<h2>Puntos centrales<\/h2>\n<ul>\n  <li><strong>Cach\u00e9 de p\u00e1gina<\/strong> mantiene bloques de archivos en la RAM y reduce las latencias.<\/li>\n  <li><strong>P\u00e1ginas sucias<\/strong> recopilan accesos de escritura y vuelven a escribir de forma agrupada.<\/li>\n  <li><strong>LRU<\/strong>Las estrategias eliminan las entradas antiguas para dar cabida a los nuevos datos.<\/li>\n  <li><strong>Monitoreo<\/strong> con free, \/proc\/meminfo, vmstat, iostat aporta claridad.<\/li>\n  <li><strong>Optimizaci\u00f3n<\/strong> mediante RAM, Logrotate, Opcache y l\u00edmites razonables.<\/li>\n<\/ul>\n\n<h2>\u00bfQu\u00e9 es la cach\u00e9 de p\u00e1ginas de Linux?<\/h2>\n<p>La cach\u00e9 de p\u00e1gina de Linux almacena bloques de archivos que se leen con frecuencia en la memoria RAM, lo que acelera cada nuevo acceso a <strong>Archivos<\/strong>. Me beneficio de inmediato, porque los accesos a la RAM se realizan en microsegundos, mientras que incluso los SSD r\u00e1pidos necesitan milisegundos y, por lo tanto, son significativamente m\u00e1s lentos que <strong>Memoria<\/strong> en la RAM. Cuando una aplicaci\u00f3n abre un archivo, el n\u00facleo almacena los bloques le\u00eddos en la cach\u00e9 y atiende las futuras solicitudes directamente desde la memoria de trabajo. Esto funciona de forma transparente para los programas, sin necesidad de ajustar ni reconfigurar nada. Las cargas de trabajo de alojamiento, como servidores web, PHP-FPM, entrega de im\u00e1genes o procesos de lectura de registros, acceden constantemente a la cach\u00e9 y ahorran E\/S.<\/p>\n\n<h2>As\u00ed funciona la cach\u00e9 durante la lectura<\/h2>\n<p>Al leer un archivo por primera vez, el sistema carga bloques en la cach\u00e9 y los marca como activos, de modo que permanecen disponibles para accesos repetidos y la <strong>Tiempo<\/strong> para el segundo requisito resulta extremadamente breve. Si leo un archivo de 100 MB dos veces seguidas, la segunda lectura se realiza pr\u00e1cticamente en su totalidad desde la RAM. El n\u00facleo utiliza estrategias como LRU (Least Recently Used) y da prioridad a las entradas utilizadas m\u00e1s recientemente, de modo que el contenido web actual permanece m\u00e1s tiempo en la cach\u00e9 y los datos fr\u00edos desaparecen. Esta l\u00f3gica encaja bien con los patrones de alojamiento, ya que muchos visitantes acceden repetidamente a im\u00e1genes, archivos CSS y JavaScript id\u00e9nticos, a los que puedo acceder gracias a <strong>Cache<\/strong> r\u00e1pidamente. La tasa de aciertos aumenta con el tama\u00f1o de la cach\u00e9, es decir, con la RAM disponible.<\/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\/2025\/12\/linux-pagecache-server-7192.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Escritura y p\u00e1ginas sucias comprensibles<\/h2>\n<p>Al escribir, los datos se almacenan primero en la cach\u00e9 como p\u00e1ginas sucias, es decir, como bloques modificados que el n\u00facleo a\u00fan no ha vuelto a escribir en el disco y que puedo recuperar mediante <strong>Writeback<\/strong>-mecanismos de forma sincronizada y oportuna. Puedo observar f\u00e1cilmente el comportamiento en directo: si creo un archivo de 10 MB con dd, los valores sucios aumentan hasta que el kernel los escribe en el SSD de una sola vez. Una sincronizaci\u00f3n manual obliga al sistema a hacer que la cach\u00e9 sea consistente y restablece la m\u00e9trica sucia a cero. Esta agrupaci\u00f3n ahorra E\/S, ya que combina muchas operaciones peque\u00f1as en transferencias m\u00e1s grandes y, por lo tanto, la <strong>Actuaci\u00f3n<\/strong> por operaci\u00f3n de escritura. El moderno enfoque de reescritura por dispositivo mantiene los discos paralelos ocupados de forma independiente y reduce los tiempos de espera.<\/p>\n\n<h2>Arquitectura de cach\u00e9: Dentry\/Inode frente a cach\u00e9 de p\u00e1gina<\/h2>\n<p>Para completar el panorama, hay que a\u00f1adir que Linux no solo almacena datos de archivos en cach\u00e9. Adem\u00e1s del propio <strong>Cach\u00e9 de p\u00e1gina<\/strong> Para los contenidos existen cach\u00e9s Dentry e Inode, que almacenan estructuras de directorios, nombres de archivos y metadatos en la RAM. Ahorran costosas resoluciones de rutas y b\u00fasquedas de inodos. En <em>free -m<\/em> estas participaciones aparecen en el valor <strong>almacenado en cach\u00e9<\/strong> tambi\u00e9n, mientras que <strong>buffers<\/strong> Me refiero m\u00e1s bien a los b\u00faferes relacionados con dispositivos de bloque. En \/proc\/meminfo puedo ver un desglose m\u00e1s detallado (por ejemplo, dentries, inactive(file), active(file)). Para las cargas de trabajo de alojamiento con muchos archivos peque\u00f1os, estas cach\u00e9s de metadatos son esenciales, ya que reducen a\u00fan m\u00e1s el n\u00famero de accesos reales al dispositivo por cada solicitud HTTP.<\/p>\n\n<h2>Interpretar correctamente los indicadores clave<\/h2>\n<p>Primero compruebo free -m y observo las columnas de cached, as\u00ed como las l\u00edneas Mem y Swap, para evaluar con seguridad el efecto de la cach\u00e9 y la <strong>Utilice<\/strong> Entender. En \/proc\/meminfo leo valores como Cached, Dirty, Writeback y Buffers, que juntos ofrecen una buena imagen del estado de la memoria. vmstat 1 muestra continuamente si el sistema est\u00e1 esperando debido a E\/S, e iostat a\u00f1ade detalles por dispositivo. Decisivo: Linux utiliza la RAM libre como cach\u00e9, pero la marca temporalmente como ocupada, aunque las aplicaciones pueden recuperarla inmediatamente si es necesario. Por lo tanto, siempre eval\u00fao la situaci\u00f3n general, incluyendo <strong>Carga de trabajo<\/strong> y no solo un n\u00famero.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>M\u00e9tricas<\/th>\n      <th>Fuente\/Comando<\/th>\n      <th>Significado<\/th>\n      <th>Se\u00f1al t\u00edpica<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>En cach\u00e9<\/td>\n      <td>free -m, \/proc\/meminfo<\/td>\n      <td>Porcentaje de RAM para datos de archivos<\/td>\n      <td>Alto valor en caso de accesos frecuentes a los archivos<\/td>\n    <\/tr>\n    <tr>\n      <td>Sucio<\/td>\n      <td>\/proc\/meminfo<\/td>\n      <td>P\u00e1ginas a\u00fan sin transcribir<\/td>\n      <td>Aumenta con escrituras intensas, disminuye tras la sincronizaci\u00f3n.<\/td>\n    <\/tr>\n    <tr>\n      <td>Writeback<\/td>\n      <td>\/proc\/meminfo<\/td>\n      <td>Operaciones de escritura activa<\/td>\n      <td>Valores distintos de cero en la fase de vaciado<\/td>\n    <\/tr>\n    <tr>\n      <td>bi\/bo (vmstat)<\/td>\n      <td>vmstat 1<\/td>\n      <td>E\/S en bloque entrada\/salida<\/td>\n      <td>Los picos indican fallos de cach\u00e9 o vaciados.<\/td>\n    <\/tr>\n    <tr>\n      <td>r\/s, w\/s (iostat)<\/td>\n      <td>iostat -xz 1<\/td>\n      <td>Operaciones de lectura\/escritura por segundo<\/td>\n      <td>Saltos en los fallos, ruido de fondo constante ok<\/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\/2025\/12\/linuxcachemeeting2347.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ventajas en el d\u00eda a d\u00eda del alojamiento web<\/h2>\n<p>Una cach\u00e9 de p\u00e1gina bien llena reduce significativamente los tiempos de espera de E\/S y traslada el acceso a los datos del disco a la RAM, lo que reduce considerablemente la latencia de las solicitudes individuales y la <strong>Tiempo de respuesta<\/strong> de las p\u00e1ginas web. Las im\u00e1genes, los archivos CSS y HTML que se utilizan con frecuencia permanecen en la cach\u00e9, de modo que el servidor web los sirve sin pasar por el SSD. Cuando hay mucho tr\u00e1fico, lo que cuenta es la tasa de aciertos: cuantas m\u00e1s repeticiones, mayor es el beneficio. En escenarios con un alto grado de paralelismo, la cach\u00e9 alivia la carga del nivel de memoria y suaviza los picos de carga. Para comprender mejor las relaciones entre las cach\u00e9s de memoria, web y proxy, vale la pena echar un vistazo a <a href=\"https:\/\/webhosting.de\/es\/caching-jerarquias-tecnologia-web-alojamiento-boost\/\">Jerarqu\u00edas de almacenamiento en cach\u00e9<\/a>, para poder utilizar cada nivel de forma adecuada y <strong>Recursos<\/strong> No lo desperdicies.<\/p>\n\n<h2>Influir de forma inteligente en el tama\u00f1o de la cach\u00e9<\/h2>\n<p>Influyo en el efecto de la cach\u00e9 de dos maneras: m\u00e1s RAM y menos accesos innecesarios a archivos, para que quede espacio libre para los datos m\u00e1s utilizados y el n\u00facleo pueda colocar los bloques correctos en la <strong>Cache<\/strong> . Logrotate con Gzip limpia los archivos de registro grandes, reduce la cantidad de archivos en la memoria y evita que los registros ocupen recursos web importantes. Siempre que puedo, marco las transferencias \u00fanicas de gran tama\u00f1o, como copias de seguridad o volcados SQL, como menos relevantes, proces\u00e1ndolas fuera de las horas punta. Solo utilizo el vaciado manual de la cach\u00e9 del n\u00facleo con echo 3 &gt; \/proc\/sys\/vm\/drop_caches en pruebas, ya que destruye la mezcla de cach\u00e9 productiva y la <strong>Latencia<\/strong> aumenta temporalmente. Al final, lo que decide es la cantidad de trabajo: cuanto mejor se adapte a la RAM, m\u00e1s constante ser\u00e1 el rendimiento.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/linux-page-cache-erklaert-7273.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>E\/S directa, fsync y consistencia<\/h2>\n<p>No todos los accesos pasan por la cach\u00e9 de p\u00e1gina. Algunas cargas de trabajo abren archivos con O_DIRECT u O_SYNC, evitando deliberadamente el almacenamiento en cach\u00e9 u obligando a la persistencia inmediata. Esto resulta \u00fatil cuando se desea evitar el almacenamiento duplicado (pool de b\u00faferes de la base de datos m\u00e1s cach\u00e9 de p\u00e1gina) o cuando la coherencia es m\u00e1s importante que la latencia. Para las cargas de trabajo web y multimedia, suelo quedarme con la E\/S normal y almacenada en b\u00fafer, porque la tasa de aciertos prevalece la mayor parte del tiempo. Tambi\u00e9n es importante comprender fsync: las aplicaciones que ejecutan fsync con frecuencia en archivos de registro impulsan los ciclos de escritura y pueden generar picos de E\/S. Siempre que puedo, agrupo estas llamadas o establezco intervalos de vaciado de aplicaciones de forma sensata para evitar el <strong>Rendimiento<\/strong> mantener en alto.<\/p>\n\n<h2>Opciones de montaje: relatime, noatime y otras.<\/h2>\n<p>Cada acceso al archivo puede actualizar el atime (tiempo de acceso) y, por lo tanto, provocar escrituras adicionales. Con <strong>relatime<\/strong> (hoy en d\u00eda est\u00e1ndar), los atimes solo se ajustan cuando es necesario, lo que reduce significativamente la E\/S. En cargas de trabajo puramente web, en las que no se utiliza la l\u00f3gica basada en atime, a menudo utilizo <strong>noatime<\/strong>, para provocar a\u00fan menos accesos de escritura. Tambi\u00e9n es relevante en la pr\u00e1ctica: tama\u00f1os de bloque adecuados, barreras predeterminadas y, si es necesario, compresi\u00f3n a nivel del sistema de archivos, si el patr\u00f3n y el margen de la CPU lo permiten. Estas opciones de montaje contribuyen directamente a una mayor tasa de aciertos de la cach\u00e9, ya que hay menos actualizaciones innecesarias de metadatos que <strong>Memoria<\/strong>-Las rutas son una carga.<\/p>\n\n<h2>Contenedores y cgroups: cach\u00e9 de p\u00e1gina en funcionamiento multitenant<\/h2>\n<p>En el alojamiento de contenedores, varias cargas de trabajo comparten la cach\u00e9 de p\u00e1gina global. Los l\u00edmites de memoria a trav\u00e9s de cgroups definen cu\u00e1nta memoria an\u00f3nima (heap\/stack) se permite por contenedor, pero la cach\u00e9 de archivos es administrada por el kernel del host. Si un contenedor se sobrecalienta y lee muchos archivos nuevos, puede desplazar las p\u00e1ginas de cach\u00e9 de otros contenedores. Por lo tanto, utilizo controles de memoria y E\/S (memory.high, memory.max, io.max) para suavizar los picos de carga y aumentar la equidad. OverlayFS, que se utiliza con frecuencia en contenedores, aporta capas de metadatos adicionales. Esto puede afectar a la resoluci\u00f3n de rutas y a las rutas de escritura \u00abcopy-on-write\u00bb. Mido espec\u00edficamente si las capas superpuestas aumentan notablemente la latencia y considero el uso de montajes vinculados sin capas adicionales para los activos est\u00e1ticos.<\/p>\n\n<h2>Precalentamiento y protecci\u00f3n de la cach\u00e9<\/h2>\n<p>Despu\u00e9s de un reinicio o de grandes implementaciones, la cach\u00e9 est\u00e1 fr\u00eda. Puedo seleccionar conjuntos calientes de forma espec\u00edfica. <strong>precalentar<\/strong>, leyendo secuencialmente los activos m\u00e1s solicitados. Esto reduce considerablemente la latencia de arranque en fr\u00edo durante los primeros minutos. Por el contrario, evito la contaminaci\u00f3n de la cach\u00e9: leo las herramientas para copias de seguridad, an\u00e1lisis de malware o grandes copias secuenciales con baja prioridad (nice\/ionice) y, si es posible, las marco como menos importantes (DONTNEED) mediante Fadvise, para que las p\u00e1ginas desaparezcan despu\u00e9s de la ejecuci\u00f3n. De este modo, la cach\u00e9 para el tr\u00e1fico web se centra en los elementos realmente importantes. <strong>Datos<\/strong>.<\/p>\n\n<h2>NUMA y hosts grandes<\/h2>\n<p>En los sistemas NUMA, la localizaci\u00f3n de la memoria juega un papel importante. La cach\u00e9 de p\u00e1gina se encuentra f\u00edsicamente en los nodos, y los accesos remotos aumentan la latencia. Presto atenci\u00f3n a que haya una vinculaci\u00f3n coherente entre la CPU y la memoria para los servicios con un acceso intensivo a los archivos y compruebo si zone_reclaim_mode es adecuado. En la pr\u00e1ctica, a menudo resulta \u00fatil agrupar los procesos web y PHP centrales por nodo NUMA, de modo que la parte m\u00e1s activa de la cach\u00e9 permanezca local. Al mismo tiempo, observo si los grandes procesos Java o de bases de datos desplazan la cach\u00e9 de p\u00e1ginas debido a sus propias necesidades de memoria; en ese caso, escalo la RAM o separo las cargas de trabajo.<\/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\/2025\/12\/linux_cache_office_4832.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NFS y memoria compartida<\/h2>\n<p>En configuraciones de cl\u00faster con NFS o sistemas de archivos de red similares, el almacenamiento en cach\u00e9 es m\u00e1s complicado. La cach\u00e9 de p\u00e1gina act\u00faa localmente en el host consumidor, mientras que los cambios en otro nodo deben invalidarse mediante protocolos. Por lo tanto, calibro las cach\u00e9s de atributos y los intervalos de invalidaci\u00f3n para mantener la coherencia sin generar demasiadas operaciones de E\/S. Para los activos web est\u00e1ticos en almacenamiento compartido, vale la pena limitar las revalidaciones y dise\u00f1ar implementaciones at\u00f3micas (por ejemplo, intercambio de directorios) para que la cach\u00e9 no se vac\u00ede innecesariamente. Siempre que es posible, replico los conjuntos activos en los nodos web individuales para obtener el m\u00e1ximo rendimiento. <strong>\u00cdndices de aciertos<\/strong> alcanzar.<\/p>\n\n<h2>Tmpfs y datos ef\u00edmeros<\/h2>\n<p>Para datos temporales que se leen con frecuencia, como archivos de sesi\u00f3n, artefactos de compilaci\u00f3n o colas de carga cortas, utilizo <strong>tmpfs<\/strong> . De este modo, ahorro completamente el acceso a los dispositivos y dejo que la cach\u00e9 de p\u00e1gina se convierta, de hecho, en el nivel de almacenamiento principal. Sin embargo, dimensiono tmpfs con cuidado: utiliza RAM (y, si es necesario, swap), y los montajes tmpfs demasiado grandes pueden ocupar espacio de otras cach\u00e9s. Un proceso de limpieza regulado (por ejemplo, systemd-tmpfiles) evita que los datos se acumulen y agoten la memoria RAM.<\/p>\n\n<h2>Patrones de carga de trabajo: peque\u00f1a frente a grande, secuencial frente a aleatoria<\/h2>\n<p>El comportamiento ideal de la cach\u00e9 depende en gran medida del patr\u00f3n. Muchos archivos peque\u00f1os y recurrentes se benefician al m\u00e1ximo de LRU y de una alta proporci\u00f3n. <strong>Activo (archivo)<\/strong>. Por el contrario, los archivos grandes que solo se leen una vez (copias de seguridad, transcodificaciones multimedia) no deber\u00edan dominar la cach\u00e9. Yo configuro read_ahead_kb de forma moderada para que los lectores secuenciales sean m\u00e1s r\u00e1pidos sin inflar los accesos aleatorios. En servidores web con muchos archivos est\u00e1ticos, activo rutas de copia cero (sendfile, splice) para evitar copias en el espacio de usuario; la cach\u00e9 de p\u00e1gina entrega entonces directamente en el socket, lo que ahorra CPU y suaviza la latencia.<\/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\/2025\/12\/linux_pagecache_schreibtisch4872.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Observaci\u00f3n ampliada y s\u00edntomas<\/h2>\n<p>Adem\u00e1s de vmstat e iostat, si es necesario, echo un vistazo a las estad\u00edsticas de recuperaci\u00f3n (por ejemplo, Active\/Inactive, pgscan\/pgsteal a trav\u00e9s de \/proc\/meminfo) para ver si el sistema est\u00e1 recuperando agresivamente p\u00e1gina por p\u00e1gina. Los fallos de p\u00e1gina importantes frecuentes, el aumento de los valores de espera de E\/S y los tiempos de reescritura persistentemente altos indican que la cach\u00e9 est\u00e1 bajo presi\u00f3n. En tales fases, primero compruebo si puedo reducir la carga de trabajo o aumentar la RAM. Si los fallos siguen siendo elevados, segmento los datos (por ejemplo, separando los archivos poco frecuentes y los activos web de uso frecuente) para que el mecanismo LRU d\u00e9 prioridad a los bloques correctos.<\/p>\n\n<h2>Reglas pr\u00e1cticas<\/h2>\n<ul>\n  <li>Estoy planeando la <strong>RAM<\/strong> de modo que los hotsets (activos web est\u00e1ticos + partes activas de bases de datos) quepan entre 1 y 2 veces. Esto duplica la probabilidad de aciertos en la cach\u00e9 durante los picos de tr\u00e1fico.<\/li>\n  <li>Evito sistem\u00e1ticamente el intercambio: tan pronto como se externalizan las p\u00e1ginas an\u00f3nimas, el paginador compite con la cach\u00e9 de p\u00e1ginas por la E\/S, lo que provoca un aumento de las latencias. Mantengo el intercambio en un nivel moderado.<\/li>\n  <li>Roto los archivos de registro m\u00e1s recientemente, comprimo las generaciones m\u00e1s antiguas y me aseguro de que los registros chatty no compitan con los activos web por espacio en la cach\u00e9.<\/li>\n  <li>Agrupo las implementaciones que modifican muchos archivos en unos pocos pasos at\u00f3micos. De este modo, invalido menos entradas de cach\u00e9 a la vez y mantengo la <strong>Tasa de aciertos<\/strong> alto.<\/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\/2025\/12\/linux-pagecache-server-7192.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sistemas de archivos y accesos a la cach\u00e9<\/h2>\n<p>El sistema de archivos influye en la eficiencia con la que el n\u00facleo almacena y escribe datos, por lo que conozco las caracter\u00edsticas de Ext4, XFS y ZFS y adapto la elecci\u00f3n a mis cargas de trabajo para que el <strong>Cache<\/strong> funciona de manera \u00f3ptima. Ext4 ofrece un rendimiento general s\u00f3lido, XFS destaca en cargas de escritura paralelas y ZFS aporta sus propios niveles de almacenamiento en cach\u00e9, como ARC. Dependiendo del patr\u00f3n (muchos archivos peque\u00f1os frente a objetos multimedia grandes), los metadatos y las rutas de escritura se comportan de manera diferente. Mido las cargas de trabajo reales antes de determinar la plataforma. Para obtener una visi\u00f3n general compacta, utilizo el art\u00edculo <a href=\"https:\/\/webhosting.de\/es\/ext4-xfs-zfs-alojamiento-rendimiento-comparacion-almacenamiento\/\">Comparaci\u00f3n entre Ext4, XFS y ZFS<\/a> y alinea ajustes como las opciones de montaje para que el kernel no realice operaciones innecesarias. <strong>Se\u00f1oras<\/strong> producido.<\/p>\n\n<h2>Bases de datos, Opcache y Page Cache<\/h2>\n<p>En MySQL y MariaDB, el b\u00fafer InnoDB almacena la mayor parte de las p\u00e1ginas de datos y los \u00edndices, mientras que la cach\u00e9 de p\u00e1gina acelera adicionalmente los bloques del sistema de archivos, reduciendo as\u00ed el I\/O total, lo que <strong>Consulta<\/strong>-Reducci\u00f3n de latencias. Configuro el buffer pool con un tama\u00f1o suficiente para que quepan los hotsets, ya que, de lo contrario, el motor produce accesos innecesarios al disco duro. Para las aplicaciones PHP, combino Opcache para el c\u00f3digo byte y APCu para los datos relacionados con la aplicaci\u00f3n, lo que reduce la presi\u00f3n sobre la cach\u00e9 de la p\u00e1gina. Los activos est\u00e1ticos siguen siendo candidatos para la cach\u00e9 del sistema de archivos y se cargan a la velocidad del rayo. Esta estratificaci\u00f3n evita el trabajo duplicado y mantiene la <strong>CPU<\/strong> libre para partes din\u00e1micas.<\/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\/2025\/12\/linux_cache_office_4832.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitorizaci\u00f3n y diagn\u00f3stico<\/h2>\n<p>Observo vmstat 1 para ver las se\u00f1ales de memoria y E\/S en tiempo real, compruebo iostat -xz 1 por dispositivo y miro en \/proc\/meminfo si hay Dirty, Cached, Writeback, para poder delimitar r\u00e1pidamente las causas y actuar de forma espec\u00edfica. <strong>actuar<\/strong> . Un valor IO-Wait elevado de forma permanente indica cuellos de botella, que primero mitigamos con cach\u00e9 y RAM. A continuaci\u00f3n, comprobamos si el sistema de archivos, RAID o el firmware SSD est\u00e1n ralentizando el sistema. Si IO-Wait sigue siendo cr\u00edtico, analizamos el acceso a las aplicaciones y las tasas de acierto del cach\u00e9. Para iniciarnos en las rutas de diagn\u00f3stico, nos ayuda <a href=\"https:\/\/webhosting.de\/es\/io-wait-comprender-cuello-de-botella-de-memoria-solucionar-optimizacion\/\">Entender IO-Wait<\/a>, para separar los s\u00edntomas de las causas y aplicar un tratamiento espec\u00edfico. <strong>Pasos<\/strong> deducir.<\/p>\n\n<h2>Par\u00e1metros de ajuste sin riesgo<\/h2>\n<p>Solo ajusto unos pocos par\u00e1metros del kernel y pruebo los cambios de forma controlada, porque existen buenos valores predeterminados y, a menudo, basta con peque\u00f1as correcciones para <strong>Eficacia<\/strong> vm.dirty_background_bytes determina el umbral a partir del cual el sistema comienza a escribir de forma as\u00edncrona, mientras que vm.dirty_bytes establece el l\u00edmite superior para las p\u00e1ginas sucias. Si se establecen estos valores en bytes en lugar de en porcentajes, se obtiene una base estable independientemente de la ampliaci\u00f3n de la RAM. Adem\u00e1s, read_ahead_kb influye en la precarga de datos por dispositivo de bloque, lo que acelera la lectura secuencial, pero permanece neutro en el caso de accesos aleatorios. Documentar\u00e9 todos los pasos y, en caso de efectos secundarios, volver\u00e9 r\u00e1pidamente a los valores originales. <strong>Valores<\/strong> ...de vuelta.<\/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\/2025\/12\/linux_pagecache_schreibtisch4872.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Breve explicaci\u00f3n de las funciones modernas<\/h2>\n<p>Las p\u00e1ginas transparentes enormes (THP) pueden agrupar p\u00e1ginas respaldadas por archivos en unidades m\u00e1s grandes, lo que reduce los costes de gesti\u00f3n por p\u00e1gina y beneficia a la TLB cuando las cargas de trabajo son demasiado grandes y contiguas. <strong>Cantidades<\/strong> En entornos de alojamiento con accesos muy aleatorios, compruebo cuidadosamente el efecto, ya que las ventajas no est\u00e1n garantizadas. Por su parte, la memoria persistente promete latencias muy bajas y abre nuevas rutas de datos que, en parte, eluden el flujo cl\u00e1sico de la cach\u00e9 de p\u00e1gina. Observo los benchmarks y sopeso si la aplicaci\u00f3n se beneficia realmente de las nuevas clases de memoria. Realizo los primeros experimentos por separado del <strong>En directo<\/strong>-Tr\u00e1fico.<\/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\/2025\/12\/linux-hosting-cache-9481.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Resumen: Lo que me llevo conmigo<\/h2>\n<p>La cach\u00e9 de p\u00e1ginas de Linux acelera las cargas de trabajo de alojamiento al trasladar las operaciones de archivo frecuentes a la RAM, lo que reduce la latencia, disminuye la carga de E\/S y mejora el rendimiento. <strong>Escala<\/strong> Mejorado. Mido valores significativos, detecto interpretaciones err\u00f3neas en free -m y utilizo \/proc\/meminfo, vmstat e iostat para obtener una visi\u00f3n completa. Con Logrotate, suficiente RAM, l\u00edmites de kernel razonables y PHP-Opcache, aumento el rendimiento sin intervenciones arriesgadas. Selecciono los sistemas de archivos teniendo en cuenta los perfiles de acceso y observo la espera de E\/S para aliviar los cuellos de botella a tiempo. De este modo, mantengo los accesos web recurrentes en la cach\u00e9, alivio la carga de la <strong>Memoria<\/strong>y entrega las p\u00e1ginas r\u00e1pidamente.<\/p>","protected":false},"excerpt":{"rendered":"<p>Almacenamiento en cach\u00e9 del sistema de archivos en el alojamiento Linux: comprender correctamente la cach\u00e9 de p\u00e1ginas de Linux y maximizar el rendimiento del servidor.<\/p>","protected":false},"author":1,"featured_media":16414,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-16421","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":"1498","_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":null,"_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 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":"16414","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/16421","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=16421"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/16421\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/16414"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=16421"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=16421"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=16421"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}