E / S disque élevées lorsque le cache est utilisé?

Il y a quelques jours, j'ai remarqué une attente d'E / S disque et une baisse d'activité du disque (ce qui était super). Ensuite, je remarque également que mon cache était plein (*) et fragmenté. Puis j'ai vidé le cache. Après cela, la latence et l'activité du disque sont passées au niveau précédent (ce qui était mauvais).

IOtop montre que [jbd2 / sda2-8] et [flush-8: 00] sont toujours au sommet de l'utilisation du disque. Il s'agit d'un Dell R210, RAID 1 matériel (H200) avec beaucoup de mémoire disponible (16 Go au total, dont environ 8 Go sont de mémoire tampon / cache).

(*) Le cache est le cache d'opcode APC pour PHP, ce qui réduit l'accès au disque pour l'exécution des scripts PHP. Le cache était plein et fragmenté car il comprenait des fichiers de l'instance de développement. Quand j'ai remarqué cela, je les ai filtrés.

La question est: pourquoi les E / S disque augmentent-elles alors qu'en théorie elles devraient diminuer? Voici quelques graphiques de munin. Le cache était plein du 6 au 8 février.

Changer après avoir commenté apc.mmap_file_mask comme dit par @ cyberx86

Et après quelques jours https://serverfault.com/a/362152/88934

Si vous utilisez un mappage de mémoire sur fichier (par exemple apc.mmap_file_mask=/tmp/apc.XXXXXX), vous pouvez voir des E / S élevées.

Essayez de configurer apc.mmap_file_maskpour utiliser la mémoire partagée (par exemple /apc.shm.XXXXXX) ou pour /dev/zero(mémoire mmappée anonyme). Si le paramètre n'est pas défini par défaut, il utilise la mémoire mmappée anonyme.

Habituellement, les fichiers mmappés sont une bonne chose:

• Par rapport au stockage complet de quelque chose en mémoire, les fichiers mappés nécessitent généralement moins de mémoire
• Par rapport à l'enregistrement de quelque chose dans un fichier, les fichiers mmappés nécessitent moins d'E / S disque (car les écritures peuvent être agrégées ensemble).

Cependant, par rapport au stockage de quelque chose de purement en mémoire, ils entraînent des E / S supplémentaires - considérablement donc lorsque le fichier change continuellement. L'inconvénient de ne pas utiliser de fichiers mmappés est un manque de persistance - votre cache ne survivra pas à un redémarrage, car il n'est stocké qu'en mémoire.

On peut donc suggérer que, tandis que le cache se remplissait et se stabilisait, il subissait le plus de changements, qui devaient être constamment écrits sur le disque; une fois que le cache était plein, le ttl pour chaque objet a ralenti la vitesse à laquelle les données du cache étaient retournées, diminuant la modification et réduisant les écritures sur disque.

Après quelques jours, je veux maintenant revenir avec quelques graphiques. Le changement améliore beaucoup cette situation. Cela réduit tout, sauf le temps de service IO (je pense que c'est parce qu'il n'y a plus de petit fichier PHP trivial lu qui est bon marché).

La charge du serveur (elle était déjà assez faible, donc je n'avais pas découvert le changement).