Puis-je configurer mon système Linux pour une mise en cache plus agressive du système de fichiers?

Je ne me préoccupe ni de l'utilisation de la RAM (j'en ai assez), ni de la perte de données en cas d'arrêt accidentel (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 je pourrais utiliser un coup de pouce de performance.

C'est pourquoi j'aimerais configurer le système pour qu'il utilise davantage de RAM pour la mise en cache de lecture et d'écriture du système de fichiers, afin de pré-extraire les fichiers de manière agressive (par exemple, la lecture à l'avance de l'intégralité du fichier auquel accède une application si le fichier est de taille raisonnable ou au moins lire à l’avance un gros morceau sinon) et vider moins souvent les tampons d’écriture. 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.

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 ( tmpfsc'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 sdaest un disque dur monté à /homeet sdbest 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_syncpour permettre à un processus unique d’obtenir un débit élevé (défini slice_syncsur nombre inférieur si vous rencontrez des situations dans lesquelles plusieurs processus attendent en parallèle des données du disque). Il slice_idles’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 quantumparamè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 quantumtrop 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_rqet slice_asyncà un nombre très bas. Cependant, si vous définissez slice_async_rqune 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à 3600000dire que 1 heure est correct pour le retard sur le disque. Gardez simplement le niveau slice_asyncbas, car sinon, vous pouvez obtenir une latence de lecture élevée.

Cette hdparmcommande 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_idlequi 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_idlesur 0donne le meilleur débit, mais que le réglage 1donne 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_factorpour é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 kswapdprocessus 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_pressureUne 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_pressuresupé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_pressureau-dessus de 100, vous exécutez sans assez de RAM. Augmenter vfs_cache_pressurepeut aider, mais la seule solution est d’obtenir plus de RAM. Définir vfs_cache_pressureun 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_ratiois 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.localet 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 /homeet /usr, faire que si votre /homeet /usrvraiment en forme dans la RAM):

(nice find /home /usr -type f -print0 | nice ionice -c 3 wc -l --files0-from - > /dev/null)&

Premièrement, je ne vous recommande PAS de continuer à utiliser NTFS, car la mise en œuvre de NTFS sous Linux poserait à tout moment un problème de performances et de sécurité.

Vous pouvez faire plusieurs choses:

• utiliser des fs plus récents tels que ext4oubtrfs
• essayez de changer votre planificateur io, par exemple bfq
• désactiver l'échange
• utiliser un préchargeur automatique comme preload
• utiliser quelque chose comme systemdpour précharger pendant le démarrage
• ... et quelque chose de plus

Peut-être que vous voulez essayer :-)

A lire d'avance:

Sur les systèmes 32 bits:

blockdev --setra 8388607 /dev/sda

Sur les systèmes 64 bits:

blockdev --setra 4294967295 /dev/sda

Écrivez en cache:

echo 100 > /proc/sys/vm/dirty_ratio

Cela utilisera jusqu'à 100% de votre mémoire libre en tant que cache en écriture.

Ou vous pouvez tout faire et utiliser tmpfs. Ceci n'est pertinent que si vous avez assez de RAM. Mettez ceci dans /etc/fstab. Remplacez 100 G par la quantité de RAM physique.

tmpfs /mnt/tmpfs tmpfs size=100G,rw,nosuid,nodev 0 0

Ensuite:

mkdir /mnt/tmpfs; mount -a

Ensuite, utilisez / mnt / tmpfs.

Vous pouvez définir la taille de lecture anticipée avec blockdev --setra sectors /dev/sda1, où secteurs est la taille souhaitée dans des secteurs de 512 octets.

Mon réglage de tueur est très simple et très efficace:

echo "2000" > /proc/sys/vm/vfs_cache_pressure

L'explication de la documentation du noyau :

vfs_cache_pressure

Contrôle la tendance du noyau à récupérer la mémoire utilisée pour la mise en cache des objets annuaire et inode.

À la valeur par défaut de vfs_cache_pressure = 100, le noyau tente de récupérer les dentiers et les inodes à un taux "raisonnable" en ce qui concerne pagecache et swapcache. La diminution de vfs_cache_pressure fait que le noyau préfère conserver les caches dentry et inode. Lorsque vfs_cache_pressure = 0, le noyau ne récupérera jamais les dentiers et les inodes à cause de la pression de la mémoire, ce qui peut facilement entraîner une saturation de la mémoire. Si vous augmentez vfs_cache_pressure au-delà de 100, le noyau préférera récupérer les dentiers et les inodes.

vfs_cache_pressure À 2000, la plupart des opérations informatiques sont effectuées dans la RAM et les écritures très tardives sur disque.

Pas lié à la mise en cache d'écriture, mais lié à l'écriture:

• Pour un système ext4, vous pouvez désactiver entièrement la journalisation.

  Cela réduira le nombre d'écritures sur disque pour une mise à jour particulière, mais risque de laisser le système de fichiers incohérent après un arrêt inattendu, nécessitant un fsck ou pire.

Pour empêcher les lectures de disque de déclencher des écritures sur disque:

• Monter avec l' option relatime ou noatime

  Lorsque vous lisez un fichier, les métadonnées de "dernière heure d'accès" pour ce fichier sont généralement mises à jour. L' noatimeoption désactivera ce comportement. Cela réduit les écritures inutiles sur le disque, mais vous ne disposerez plus de ces métadonnées. Certaines distributions (Manjaro, par exemple) ont adopté cette option par défaut sur toutes les partitions (probablement pour augmenter la durée de vie des modèles SSD précédents).

  relatimemet à jour le temps d'accès moins fréquemment, selon des méthodes heuristiques permettant de prendre en charge les applications utilisant atime. C'est la valeur par défaut sous Red Hat Enterprise Linux.

Autres options:

• Dans les commentaires ci-dessus, Mikko a partagé la possibilité de monter avec l' option nobarrier . Mais Ivailo a cité RedHat qui a mis en garde contre cela. À quel point voulez-vous que ces 3% supplémentaires?