Je ne suis ni préoccupé par l'utilisation de la RAM (car j'en ai assez) ni par la perte de données en cas d'arrêt accidentel (comme mon alimentation est sauvegardée, le système est fiable et les données ne sont pas critiques). Mais je fais beaucoup de traitement de fichiers et j'aurais besoin d'une amélioration des performances.
C'est pourquoi j'aimerais configurer le système pour qu'il utilise plus de RAM pour la mise en cache en lecture et en écriture du système de fichiers, pour prérécupérer les fichiers de manière agressive (par exemple, lire à l'avance tout le fichier auquel une application accède au cas où le fichier est de taille saine ou au moins lire à l'avance une grande partie sinon) et pour vider les tampons d'écriture moins fréquemment. Comment y parvenir (est-ce possible) ?
J'utilise les systèmes de fichiers ext3 et ntfs (j'utilise beaucoup ntfs !) avec XUbuntu 11.10 x86.
Réponse acceptée :
L'amélioration des performances du cache disque en général ne se limite pas à augmenter la taille du cache du système de fichiers, à moins que votre tout le système tient dans la RAM auquel cas vous devez utiliser le lecteur RAM (tmpfs est bon car il permet de revenir sur le disque si vous avez besoin de la RAM dans certains cas) pour le stockage d'exécution (et peut-être un script initrd pour copier le système du stockage vers le lecteur RAM au démarrage).
Vous n'avez pas dit si votre périphérique de stockage est un SSD ou un HDD. Voici ce que j'ai trouvé pour travailler pour moi (dans mon cas sda est un disque dur monté sur /home et sdb est un SSD monté sur / ).
Optimisez d'abord la partie load-stuff-from-storage-to-cache :
Voici ma configuration pour le disque dur (assurez-vous que AHCI + NCQ est activé dans le BIOS si vous avez des bascules):
echo cfq > /sys/block/sda/queue/scheduler
echo 10000 > /sys/block/sda/queue/iosched/fifo_expire_async
echo 250 > /sys/block/sda/queue/iosched/fifo_expire_sync
echo 80 > /sys/block/sda/queue/iosched/slice_async
echo 1 > /sys/block/sda/queue/iosched/low_latency
echo 6 > /sys/block/sda/queue/iosched/quantum
echo 5 > /sys/block/sda/queue/iosched/slice_async_rq
echo 3 > /sys/block/sda/queue/iosched/slice_idle
echo 100 > /sys/block/sda/queue/iosched/slice_sync
hdparm -q -M 254 /dev/sda
A noter que le cas du disque dur est élevé fifo_expire_async (généralement écrit) et long slice_sync pour permettre à un seul processus d'obtenir un débit élevé (définissez slice_sync pour réduire le nombre si vous rencontrez des situations où plusieurs processus attendent certaines données du disque en parallèle). Le slice_idle est toujours un compromis pour les disques durs, mais le régler quelque part dans la plage 3-20 devrait convenir en fonction de l'utilisation du disque et du micrologiciel du disque. Je préfère cibler des valeurs faibles, mais le définir trop bas détruira votre débit. Le quantum le réglage semble beaucoup affecter le débit, mais essayez de le maintenir aussi bas que possible pour maintenir la latence à un niveau raisonnable. Réglage quantum trop faible détruira le débit. Les valeurs comprises entre 3 et 8 semblent bien fonctionner avec les disques durs. La latence la plus défavorable pour une lecture est (quantum * slice_sync ) + (slice_async_rq * slice_async ) ms si j'ai bien compris le comportement du noyau. L'async est principalement utilisé par les écritures et puisque vous êtes prêt à retarder l'écriture sur le disque, définissez les deux slice_async_rq et slice_async à des nombres très faibles. Cependant, la définition de slice_async_rq une valeur trop faible peut bloquer les lectures car les écritures ne peuvent plus être retardées après les lectures. Ma configuration essaiera d'écrire des données sur le disque au plus tard 10 secondes après la transmission des données au noyau, mais comme vous pouvez tolérer la perte de données en cas de coupure de courant, définissez également fifo_expire_async à 3600000 dire que 1 heure est acceptable pour le délai sur le disque. Gardez juste le slice_async faible, car sinon vous pouvez obtenir une latence de lecture élevée.
Le hdparm La commande est requise pour empêcher AAM de tuer une grande partie des performances autorisées par AHCI + NCQ. Si votre disque fait trop de bruit, passez cette étape.
Voici ma configuration pour SSD (série Intel 320) :
echo cfq > /sys/block/sdb/queue/scheduler
echo 1 > /sys/block/sdb/queue/iosched/back_seek_penalty
echo 10000 > /sys/block/sdb/queue/iosched/fifo_expire_async
echo 20 > /sys/block/sdb/queue/iosched/fifo_expire_sync
echo 1 > /sys/block/sdb/queue/iosched/low_latency
echo 6 > /sys/block/sdb/queue/iosched/quantum
echo 2 > /sys/block/sdb/queue/iosched/slice_async
echo 10 > /sys/block/sdb/queue/iosched/slice_async_rq
echo 1 > /sys/block/sdb/queue/iosched/slice_idle
echo 20 > /sys/block/sdb/queue/iosched/slice_sync
Ici, il convient de noter les faibles valeurs pour différents paramètres de tranche. Le paramètre le plus important pour un SSD est slice_idle qui doit être réglé sur 0-1. Le mettre à zéro déplace toutes les décisions de tri vers le NCQ natif tandis que le mettre à 1 permet au noyau de trier les requêtes (mais si le NCQ est actif, le matériel peut remplacer partiellement le tri du noyau). Testez les deux valeurs pour voir si vous pouvez voir la différence. Pour la série Intel 320, il semble que le paramètre slide_idle à donne le meilleur débit mais en le réglant sur 1 donne la meilleure (la plus faible) latence globale.
Pour plus d'informations sur ces paramètres réglables, consultez https://www.kernel.org/doc/Documentation/block/cfq-iosched.txt .
Mise à jour en 2020 et version 5.3 du noyau (cfq est mort) :
modprobe bfq
for d in /sys/block/sd?
do
# HDD (tuned for Seagate SMR drive)
echo bfq > "$d/queue/scheduler"
echo 4 > "$d/queue/nr_requests"
echo 32000 > "$d/queue/iosched/back_seek_max"
echo 3 > "$d/queue/iosched/back_seek_penalty"
echo 80 > "$d/queue/iosched/fifo_expire_sync"
echo 1000 > "$d/queue/iosched/fifo_expire_async"
echo 5300 > "$d/queue/iosched/slice_idle_us"
echo 1 > "$d/queue/iosched/low_latency"
echo 200 > "$d/queue/iosched/timeout_sync"
echo 0 > "$d/queue/iosched/max_budget"
echo 1 > "$d/queue/iosched/strict_guarantees"
# additional tweaks for SSD (tuned for Samsung EVO 850):
if test $(cat "$d/queue/rotational") = "0"
then
echo 36 > "$d/queue/nr_requests"
echo 1 > "$d/queue/iosched/back_seek_penalty"
# slice_idle_us should be ~ 0.7/IOPS in µs
echo 16 > "$d/queue/iosched/slice_idle_us"
echo 10 > "$d/queue/iosched/fifo_expire_sync"
echo 250 > "$d/queue/iosched/fifo_expire_async"
echo 10 > "$d/queue/iosched/timeout_sync"
echo 0 > "$d/queue/iosched/strict_guarantees"
fi
done
La configuration est assez similaire mais j'utilise maintenant bfq au lieu de cfq car ce dernier n'est pas disponible avec les noyaux modernes. J'essaie de conserver nr_requests aussi bas que possible pour autoriser bfq pour contrôler plus précisément la planification. Au moins, les disques SSD Samsung semblent nécessiter une file d'attente assez longue pour pouvoir fonctionner avec des IOPS élevés.
J'utilise Ubuntu 18.04 avec le paquet de noyau linux-lowlatency-hwe-18.04-edge qui a bfq uniquement en tant que module donc je dois le charger avant de pouvoir y basculer.
J'utilise aussi aujourd'hui zram mais je n'utilise que 5% de RAM pour zram. Cela permet au noyau Linux d'utiliser la logique liée à l'échange sans toucher aux disques. Cependant, si vous décidez d'opter pour un échange de disque sans échange, assurez-vous que vos applications ne fuient pas la RAM ou que vous gaspillez de l'argent.
Maintenant que nous avons configuré le noyau pour charger des éléments du disque vers le cache avec des performances raisonnables, il est temps d'ajuster le comportement du cache :
Selon les benchmarks que j'ai effectués, je ne prendrais pas la peine de lire à l'avance via blockdev du tout. Les paramètres par défaut du noyau sont corrects.
Configurez le système pour qu'il préfère échanger les données du fichier plutôt que le code de l'application (cela n'a pas d'importance si vous disposez de suffisamment de RAM pour conserver l'intégralité système de fichiers et tout le code d'application et toute la mémoire virtuelle allouée par les applications en RAM). Cela réduit la latence pour permuter entre différentes applications par rapport à la latence pour accéder à de gros fichiers à partir d'une seule application :
echo 15 > /proc/sys/vm/swappiness
Si vous préférez conserver presque toujours les applications dans la RAM, vous pouvez définir ce paramètre sur 1. Si vous le définissez sur zéro, le noyau ne permutera pas du tout, sauf en cas d'absolue nécessité pour éviter le OOM. Si votre mémoire était limitée et que vous travailliez avec des fichiers volumineux (par exemple, le montage vidéo HD), il serait peut-être judicieux de définir cette valeur à proximité de 100.
De nos jours (2017), je préfère ne pas avoir d'échange du tout si vous avez suffisamment de RAM. L'absence d'échange entraînera généralement la perte de 200 à 1 000 Mo de RAM sur un ordinateur de bureau de longue durée. Je suis prêt à sacrifier autant pour éviter la latence du pire des cas (échange de code d'application lorsque la RAM est pleine). En pratique, cela signifie que je préfère OOM Killer à l'échange. Si vous autorisez/nécessitez l'échange, vous pouvez augmenter /proc/sys/vm/watermark_scale_factor , aussi, pour éviter une certaine latence. Je suggérerais des valeurs comprises entre 100 et 500. Vous pouvez considérer ce paramètre comme un échange d'utilisation du processeur pour une latence d'échange plus faible. La valeur par défaut est 10 et le maximum possible est 1000. Une valeur plus élevée devrait (selon la documentation du noyau) entraîner une utilisation plus élevée du processeur pour kswapd processus et réduire la latence globale de permutation.
Ensuite, dites au noyau de préférer conserver la hiérarchie des répertoires en mémoire plutôt que le contenu des fichiers au cas où de la RAM devrait être libérée (encore une fois, si tout tient dans la RAM, ce paramètre ne fait rien) :
echo 10 > /proc/sys/vm/vfs_cache_pressure
Définition de vfs_cache_pressure une valeur faible est logique car dans la plupart des cas, le noyau doit connaître la structure du répertoire avant de pouvoir utiliser le contenu du fichier du cache et vider le cache du répertoire trop tôt rendra le cache du fichier presque sans valeur. Envisagez de descendre jusqu'à 1 avec ce paramètre si vous avez beaucoup de petits fichiers (mon système contient environ 150 000 photos de 10 mégapixels et compte comme un système "beaucoup de petits fichiers"). Ne le réglez jamais sur zéro ou la structure des répertoires est toujours conservée en mémoire même si le système manque de mémoire. Définir cette valeur sur grande n'est judicieux que si vous n'avez que quelques gros fichiers qui sont constamment relus (encore une fois, le montage vidéo HD sans suffisamment de RAM serait un exemple). La documentation officielle du noyau indique que "l'augmentation significative de vfs_cache_pressure au-delà de 100 peut avoir un impact négatif sur les performances".
Exception : si vous avez une quantité vraiment énorme de fichiers et de répertoires et que vous touchez/lisez/listez rarement tous les fichiers en définissant vfs_cache_pressure supérieur à 100 peut être judicieux. Cela ne s'applique que si vous ne disposez pas de suffisamment de RAM et que vous ne pouvez pas conserver toute la structure de répertoires dans la RAM et que vous disposez toujours de suffisamment de RAM pour le cache et les processus de fichiers normaux (par exemple, un serveur de fichiers à l'échelle de l'entreprise avec beaucoup de contenu d'archivage). Si vous pensez que vous devez augmenter vfs_cache_pressure au-dessus de 100, vous exécutez sans assez de RAM. Augmenter vfs_cache_pressure peut aider, mais la seule vraie solution est d'obtenir plus de RAM. Avoir vfs_cache_pressure définir un nombre élevé sacrifie les performances moyennes pour avoir des performances globales plus stables (c'est-à-dire que vous pouvez éviter un comportement vraiment mauvais dans le pire des cas, mais que vous devez faire face à des performances globales inférieures).
Enfin, dites au noyau d'utiliser jusqu'à 99 % de la RAM comme cache pour les écritures et demandez au noyau d'utiliser jusqu'à 50 % de la RAM avant de ralentir le processus d'écriture (par défaut pour dirty_background_ratio est 10 ). Attention :Personnellement, je ne ferais pas cela, mais vous prétendez avoir suffisamment de RAM et êtes prêt à perdre les données.
echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio
Et dites qu'un délai d'écriture de 1h est acceptable pour même démarrer écrire des trucs sur le disque (encore une fois, je ne ferais pas ça):
echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs
Pour plus d'informations sur ces paramètres réglables, consultez https://www.kernel.org/doc/Documentation/sysctl/vm.txt
Si vous mettez tout cela dans /etc/rc.local et inclure ce qui suit à la fin, tout sera dans le cache dès que possible après le démarrage (ne le faites que si votre système de fichiers tient vraiment dans la RAM) :
(nice find / -type f -and -not -path '/sys/*' -and -not -path '/proc/*' -print0 2>/dev/null | nice ionice -c 3 wc -l --files0-from - > /dev/null)&
Ou une alternative un peu plus simple qui pourrait mieux fonctionner (cache uniquement /home et /usr , ne le faites que si votre /home et /usr tient vraiment dans la RAM):
(nice find /home /usr -type f -print0 | nice ionice -c 3 wc -l --files0-from - > /dev/null)&