Vous voulez quelques choses. Tout d'abord, vous voulez réduire la swappiness
sysctl -w vm.swappiness=10
Cela permettra d'économiser quelques E/S disque ; parce que la dernière chose dont vous avez besoin, ce sont des écritures supplémentaires sur le disque lorsque le noyau tente de paginer certaines choses de la mémoire. L'objectif est de régler les choses de sorte que le moins de swapping possible soit nécessaire. Cependant, ne désactivez pas la swappiness en la réglant à 0 ou en la désactivant. Je recommanderais une action extrême d'aller jusqu'à régler la swappiness à 1. Si vous observez la sortie de dstat pendant un certain temps, vous remarquerez rapidement combien de données sont réellement écrites et lues depuis le swap.
Maintenant, il existe un mécanisme dans les noyaux plus récents (3.2+) appelé writeback throttling. Pour pouvoir l'utiliser comme vous l'avez dit, vous devez régler les ratios sales. Consultez plus de détails sur ce lien. La citation qui vous intéresse est la suivante
Une fois la limite de dirty_ratio (respectivement dirty_bytes) atteinte, le processus qui
écrit est ralenti.
Par défaut, les paramètres de dirty sont plutôt élevés, surtout si vous avez beaucoup de mémoire et un sous-système de disque lent. Vous devez donc les régler à la baisse ; aussi bas que possible sans affecter une utilisation normale* et pourtant la valeur dictera le volume de données qui existera en mémoire avant que le noyau ne lance des processus pour écrire ces données sur le disque, lorsque votre situation de goulot d'étranglement E/S disque commence à se produire. À ce moment-là, vous voulez que ce processus soit ralenti, ce que le noyau fait en injectant des attentes dedans.
*Pour comprendre ce qui est une utilisation normale ; je recommanderais d'installer atop et d'observer ce qui s'y passe; vous souhaitez vérifier les chiffres de dirty là-bas et voir l'aperçu D où les lectures/écritures disque sont suivies. Il y a une colonne WCANCL; ce sont en fait des écritures qui ont été traitées en mémoire et qui n'ont jamais été nécessaires à écrire sur le disque (pages sales) mais pour des données temporaires. Mysql en a lorsque ça effectue des requêtes complexes, le compilateur lorsqu'il crée une multitude de petits fichiers obj qui ne seront pas nécessaires longtemps, etc...
En dehors de cela, il peut être utile de passer au planificateur de disque deadline et d'ajuster l'affinité des lectures par rapport aux écritures pour mieux correspondre à votre environnement. Par exemple, si vous faites 10 fois plus de lectures que d'écritures, vous voudrez peut-être régler
/sys/block//queue/iosched/writes_starved
à 5 plutôt que 2 par défaut. Augmenter
/sys/block//queue/iosched/write_expire
vous aidera également. De plus, vous pouvez gagner en latence si vous diminuez le nombre de requêtes effectuées en lot de 128 à disons 32
/sys/block//queue/nr_requests
