¿Alta E / S de disco cuando se usa caché?

Hace unos días noté una espera de E / S de disco y una caída en la actividad del disco (lo cual fue genial). Entonces también noté que mi caché estaba llena (*) y fragmentada. Luego enjuagué el caché. Después de eso, la latencia del disco y la actividad del disco saltaron al nivel anterior (que era malo).

IOtop muestra que [jbd2 / sda2-8] y [flush-8: 00] siempre están por encima del uso del disco. Este es un Dell R210, hardware RAID 1 (H200) con una gran cantidad de memoria libre (16 GB en total, de los cuales aproximadamente 8 GB son búfer / caché).

(*) El caché es un caché de código de operación APC para PHP, lo que reduce el acceso al disco para la ejecución del script PHP. La memoria caché estaba llena y fragmentada porque incluía archivos de la instancia de desarrollo. Cuando me di cuenta de eso, los filtré.

La pregunta es: ¿por qué la E / S de disco aumenta cuando teóricamente debería disminuir? A continuación hay algunos gráficos de munin. La caché estuvo llena del 6 al 8 de febrero.

Cambie después de comentar apc.mmap_file_mask según lo dicho por @ cyberx86

Y después de unos días https://serverfault.com/a/362152/88934

Si utiliza la asignación de memoria respaldada por archivos (por ejemplo apc.mmap_file_mask=/tmp/apc.XXXXXX), es posible que vea E / S elevadas.

Intente configurar apc.mmap_file_maskpara usar la memoria compartida (por ejemplo /apc.shm.XXXXXX) o para /dev/zero(memoria anónima mmapped). Al mantener la configuración indefinida, el valor predeterminado es usar memoria mmapped anónima.

Por lo general, los archivos mmapped son una gran cosa:

• En comparación con el almacenamiento de algo completamente en la memoria, los archivos mmapped generalmente requieren menos memoria
• En comparación con guardar algo en un archivo, los archivos mmapped requieren menos E / S de disco (ya que las escrituras se pueden agregar juntas).

Sin embargo, en comparación con el almacenamiento de algo puramente en la memoria, incurren en E / S adicionales, considerablemente cuando el archivo cambia continuamente. La desventaja de no usar archivos mmapped es la falta de persistencia: su caché no sobrevivirá a un reinicio, ya que se almacena solo en la memoria.

Por lo tanto, se puede sugerir que mientras el caché se estaba llenando y estabilizando, estaba experimentando la mayor parte del cambio, que tenía que escribirse constantemente en el disco; una vez que el caché estaba lleno, el ttl para cada objeto redujo la velocidad a la que se entregaban los datos en el caché, disminuyendo el cambio y reduciendo las escrituras en disco.

Después de unos días, ahora quiero volver con algunos gráficos. El cambio mejora mucho esa situación. Reduce todo, excepto el tiempo de servicio IO (creo que es porque ya no hay una lectura trivial de archivos PHP pequeños que es barata).

La carga del servidor (ya era bastante baja, así que no había descubierto el cambio).