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


119

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.


6
Si vous avez beaucoup de mémoire vive, si vous vous souciez des performances et de la perte de données, copiez toutes vos données sur un disque virtuel et transmettez-les à partir de cet emplacement, en supprimant toutes les mises à jour en cas de panne ou d'arrêt. Si cela ne fonctionne pas pour vous, vous devrez peut-être vous qualifier «suffisamment» pour la RAM ou à quel point les données ne sont pas critiques.
James Youngman

1
@ Nils, l'ordinateur est un ordinateur portable, donc, je crois, le contrôleur est assez ordinaire.
Ivan

1
Une façon d'améliorer beaucoup les performances consiste à ignorer la durabilité des données. Désactivez simplement la synchronisation sur disque même si certaines applications demandent une synchronisation. Cela entraînera une perte de données si votre périphérique de stockage subit une perte d'électricité. Si vous voulez quand même le faire, exécutez sudo mount -o ro,nobarrier /path/to/mountpointou ajustez simplement /etc/fstabpour inclure nobarriertout système de fichiers que vous êtes prêt à sacrifier pour améliorer les performances. Toutefois, si votre périphérique de stockage dispose d'une batterie interne telle que la série Intel 320 SSD, l'utilisation nobarrierne provoque aucune perte de données.
Mikko Rantalainen

1
L’utilisation de nobarrier n’est plus recommandée dans Red Hat Enterprise Linux 6 car l’impact négatif des barrières en écriture sur la performance est négligeable (environ 3%). Les avantages des barrières en écriture l'emportent généralement sur les avantages de les désactiver en termes de performances. De plus, l'option nobarrier ne doit jamais être utilisée sur un stockage configuré sur des machines virtuelles. access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/…
Ivailo Bardarov

1
Deux points - 1) Il existe des distributions Linux basées sur Debian ou Ubuntu, comme Puppy Linux et AntiX Linux, et bien d’autres qui placent l’ensemble du système d’exploitation dans des partitions superposées de disques (ex. AUFS ou overlayfs) et le gèrent de manière transparente. Très vite! - 2) Nous avons découvert, dans le monde réel, un très grand système qui permettait de réduire davantage le cache, ce qui réduirait les performances. Lorsque la vitesse de stockage augmente (SSD, par exemple), la taille optimale du cache nécessaire diminue. Pas moyen de savoir quelle est cette taille sans expérimenter sur votre système particulier. Si augmenter ne fonctionne pas, essayez de le réduire.
DocSalvager

Réponses:


107

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)&

3
Une réponse bien informée et globalement bien meilleure que celle acceptée! Celui-ci est sous-estimé ... Je suppose que la plupart des gens veulent juste des instructions simples sans se soucier de comprendre ce qu'ils font vraiment ...
Vladimir Panteleev

2
@Phpdevpad: En outre, la question disait: "Je ne suis pas préoccupé par l'utilisation de la RAM [...]" - Je ne pense pas qu'un périphérique Maemo soit admissible.
Mikko Rantalainen

1
Noop ou date limite n'est-il pas un meilleur ordonnanceur pour les SSD?
rep_movsd

1
@rep_movsd J'utilise uniquement des lecteurs SSD Intel, mais au moins ces lecteurs sont encore suffisamment lents pour offrir de meilleures performances globales avec des planificateurs plus intelligents tels que CFQ. J'imagine que si votre disque SSD peut traiter plus de 100 000 IOPS aléatoires, utiliser noop ou délai serait logique même avec un processeur rapide. Par "processeur rapide", je veux dire quelque chose qui a au moins plusieurs cœurs 3GHz disponibles pour IO uniquement.
Mikko Rantalainen

1
Vous pouvez également en savoir plus sur ces paramètres ajustables vm à partir de la documentation du noyau vm .
joeytwiddle

16

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 :-)


1
Une fois, je suis déjà passé complètement de NTFS à ext4 une fois, laissant la seule partition NTFS à être la partition système Windows. Mais cela a eu de nombreux inconvénients pour moi et je suis revenu à NTFS en tant que partition de données principale (où je stocke tous mes documents, téléchargements, projets, code source, etc.). Je ne renonce pas à repenser la structure de mes partitions et mon flux de travail (utiliser moins Windows), mais abandonner maintenant NTFS ne semble pas une option réaliste.
Ivan

Si vous devez également utiliser vos données dans Windows, NTFS peut être la seule option. (beaucoup d'autres options disponibles si vous pouvez utiliser votre Windows comme une machine virtuelle sous Linux)
Felix Yan

1
Un résumé de ces problèmes supposés de NTFS aurait été utile.
underscore_d

2
NTFS sur Linux est assez acceptable, sauf pour les performances. Considérant que la question portait spécifiquement sur l'amélioration des performances du système de fichiers, NTFS devrait être la première chose à faire.
Mikko Rantalainen

Même s’il btrfss’agit d’un système de fichiers récemment conçu, j’éviterais cela si des performances sont nécessaires. Nous avons mis en place par ailleurs des systèmes identiques avec btrfset les ext4systèmes de fichiers et ext4gagne dans le monde réel avec une grande marge ( btrfsSemble besoin d' environ 4x temps CPU les ext4besoins pour le même niveau de performance et provoque plusieurs opérations de disque pour une seule commande logique). Selon la charge de travail, je le suggérerais ext4, jfsou xfspour tout travail exigeant en termes de performances.
Mikko Rantalainen

8

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.


5
Lecture anticipée de 3 Go ou 2 To? vraiment? Savez-vous même ce que font ces options?
Cobra_Fast

1
@ Cobra_Fast Savez-vous ce que cela signifie? Je n'ai vraiment aucune idée et je suis intéressé maintenant.
Syss

3
@syss les paramètres readahead sont enregistrés en tant que nombre de "blocs" de mémoire, et non en octets ou en bits. La taille d'un bloc est déterminée au moment de la compilation du noyau (car les blocs readahead sont des blocs de mémoire) ou au moment de la création du système de fichiers dans certains cas. Normalement, un bloc contient 512 ou 4096 octets. Voir linux.die.net/man/8/blockdev
Cobra_Fast

6

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.


2

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.


4
Un réglage vfs_cache_pressuretrop élevé (à mon avis 2000trop élevé) entraînera un accès inutile au disque, même pour des choses simples telles que les listes de répertoires qui devraient facilement tenir dans le cache. Combien de RAM avez-vous et que faites-vous avec le système? Comme je l'ai écrit dans ma réponse, l'utilisation de valeurs élevées pour ce paramètre est utile, par exemple, pour l'édition vidéo HD avec une RAM limitée.
Mikko Rantalainen

2
Notez que la documentation référencée continue: " L'augmentation significative de vfs_cache_pressure au-delà de 100 peut avoir un impact négatif sur les performances. Le code de récupération a besoin de plusieurs verrous pour trouver des objets répertoire et inode libres. Avec vfs_cache_pressure = 1000, il recherchera dix fois plus d'objets libres que celui-ci. sont."
Mikko Rantalainen

1

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?
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.