En général, améliorer les performances du cache disque ne consiste pas simplement à augmenter la taille du cache du système de fichiers, à moins que l' ensemble de votre système ne tienne dans la RAM. Dans ce cas, vous devez utiliser un lecteur RAM ( tmpfs
c'est bien, car cela permet de recourir au disque si vous avez besoin de RAM dans certains cas). pour le stockage à l'exécution (et peut-être un script initrd pour copier le système du stockage sur le lecteur RAM au démarrage).
Vous n'avez pas indiqué si votre périphérique de stockage est un disque SSD ou un disque dur. Voici ce que j'ai trouvé pour travailler pour moi (dans mon cas sda
est un disque dur monté à /home
et sdb
est monté sur SSD /
).
D'abord, optimisez 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 basculé):
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
Il convient de noter que le disque dur est haut fifo_expire_async
(généralement en écriture) et long slice_sync
pour permettre à un processus unique d’obtenir un débit élevé (défini slice_sync
sur nombre inférieur si vous rencontrez des situations dans lesquelles plusieurs processus attendent en parallèle des données du disque). Il slice_idle
s’agit toujours d’un compromis pour les disques durs, mais son réglage dans la plage 3-20 devrait être correct, en fonction de l’utilisation du disque et du microprogramme du disque. Je préfère cibler les valeurs les plus basses, mais une valeur trop basse détruira votre débit. Le quantum
paramètre semble affecter beaucoup le débit, mais essayez de le maintenir aussi bas que possible pour maintenir la latence à un niveau raisonnable. Un réglage quantum
trop bas 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. Le async est surtout utilisé par écrit et que vous êtes prêt à retarder l' écriture sur le disque, définir à la fois slice_async_rq
et slice_async
à un nombre très bas. Cependant, si vous définissez slice_async_rq
une valeur trop basse, les lectures seront bloquées car les écritures ne pourront plus être différées. Ma config essayera d'écrire des données sur le disque au plus après 10 secondes après que les données ont été transmis au noyau , mais puisque vous pouvez tolérer la perte de données sur la perte de puissance également mis fifo_expire_async
à 3600000
dire que 1 heure est correct pour le retard sur le disque. Gardez simplement le niveau slice_async
bas, car sinon, vous pouvez obtenir une latence de lecture élevée.
Cette hdparm
commande est nécessaire pour empêcher AAM de compromettre une grande partie des performances permises par AHCI + NCQ. Si votre disque fait trop de bruit, sautez ceci.
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 celui slice_idle
qui doit être défini sur 0-1. Définir cette valeur sur zéro déplace toutes les décisions de commande vers NCQ natif, tandis que la valeur 1 permet au noyau de commander des demandes (mais si le NCQ est actif, le matériel peut annuler partiellement la commande 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 réglage slide_idle
sur 0
donne le meilleur débit, mais que le réglage 1
donne la meilleure latence (la plus faible).
Pour plus d'informations sur ces paramètres ajustables, voir http://www.linux-mag.com/id/7572/ .
Maintenant que nous avons configuré le noyau pour charger des éléments d'un disque à un autre avec des performances raisonnables, il est temps d'ajuster le comportement du cache:
Selon les repères que j'ai faits, je ne me donnerais pas la peine de passer à lire avant blockdev
. Les paramètres par défaut du noyau conviennent.
Définissez le système pour qu'il préfère échanger les données du fichier sur le code de l'application (peu importe si vous disposez de suffisamment de RAM pour conserver le système de fichiers complet, ainsi que tout le code de l'application et toute la mémoire virtuelle allouée par les applications dans la RAM). Cela réduit la latence pour le basculement entre différentes applications sur la latence pour l'accès à des fichiers volumineux à partir d'une seule application:
echo 15 > /proc/sys/vm/swappiness
Si vous préférez conserver les applications presque toujours dans la RAM, vous pouvez définir la valeur 1. Si vous définissez la valeur sur zéro, le noyau ne sera pas échangé du tout, à moins que cela ne soit absolument nécessaire pour éviter OOM. Si vous étiez limité en mémoire et travailliez avec de gros fichiers (par exemple, l'édition vidéo HD), il serait peut-être judicieux de choisir une valeur proche de 100.
De nos jours (2017), je préfère ne pas avoir d'échange du tout si vous avez assez de RAM. Le fait de ne pas permuter perdra généralement 200 à 1 000 Mo de RAM sur un ordinateur de bureau fonctionnant longtemps. Je suis prêt à sacrifier autant pour éviter la latence dans le pire des cas (remplacement du code d'application lorsque la mémoire RAM est saturée). Dans la pratique, cela signifie que je préfère le tueur OOM à l’échange. Si vous autorisez / avez besoin d’échange, vous voudrez peut-être également augmenter /proc/sys/vm/watermark_scale_factor
pour éviter une certaine latence. Je suggérerais des valeurs comprises entre 100 et 500. Vous pouvez considérer ce paramètre comme un usage commercial du processeur pour une latence de swap inférieure. La valeur par défaut est 10 et la valeur maximale possible est 1 000. Une valeur supérieure doit (selon la documentation du noyau ) entraîner une utilisation accrue de la CPU pour les kswapd
processus et une latence de swap globale inférieure.
Ensuite, dites au noyau de préférer garder la hiérarchie des répertoires en mémoire plutôt que le contenu du fichier 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
Réglage vfs_cache_pressure
Une valeur faible a du sens car dans la plupart des cas, le noyau a besoin de connaître la structure des répertoires pour pouvoir utiliser le contenu des fichiers du cache et vider le cache de répertoires trop tôt, ce qui rend le cache de fichiers presque inutile. Si vous avez beaucoup de petits fichiers (envisagez environ 150 000 photos 10 mégapixels, mon système compte environ 1 000 photos) et compte comme système "beaucoup de petits fichiers". Ne le définissez jamais à zéro ou la structure de répertoire est toujours conservée en mémoire, même si le système est à court de mémoire. Définir ce paramètre sur une valeur élevée n’est judicieux que si vous ne disposez que de quelques gros fichiers qui sont constamment relus (encore une fois, l’édition de vidéos HD sans assez de RAM serait un exemple). La documentation officielle du noyau indique que "
Exception: si vous avez vraiment une quantité énorme de fichiers et de répertoires et que vous touchez / lisez / listez rarement tous les fichiers dont la valeur est vfs_cache_pressure
supérieure à 100, cela peut être judicieux. Cela ne s'applique que si vous ne disposez pas de suffisamment de RAM et que vous ne pouvez pas conserver la structure de répertoires dans celle-ci tout en conservant assez de RAM pour le cache et les processus normaux (par exemple, le serveur de fichiers de la société avec beaucoup de contenu archivistique). Si vous sentez 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 solution est d’obtenir plus de RAM. Définir vfs_cache_pressure
un nombre élevé sacrifie les performances moyennes pour obtenir des performances globalement plus stables (vous pouvez éviter le pire comportement, mais vous devez faire face à des performances globales pires).
Enfin, indiquez au noyau d'utiliser jusqu'à 99% de la RAM en cache pour les écritures et demandez au noyau d'utiliser jusqu'à 50% de la RAM avant de ralentir le processus en cours d'écriture (par défaut pour dirty_background_ratio
is 10
). Avertissement: Personnellement, je ne le ferais pas, mais vous avez prétendu disposer de 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 correct pour même commencer à écrire des éléments sur le disque (encore une fois, je ne le ferais pas):
echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs
Si vous mettez tous ces éléments dans /etc/rc.local
et incluez ce qui suit à la fin, tout sera mis en 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 un peu plus simple alternative pourrait mieux fonctionner (cache seulement /home
et /usr
, faire que si votre /home
et /usr
vraiment en forme dans la RAM):
(nice find /home /usr -type f -print0 | nice ionice -c 3 wc -l --files0-from - > /dev/null)&