Réglage du comportement de mise en cache du disque Linux pour un débit maximal

Je rencontre un problème de débit maximum ici et j'ai besoin de conseils sur la façon de régler mes boutons. Nous exécutons un serveur de fichiers 10 Gbit pour la distribution de sauvegarde. Il s'agit d'une configuration S-ATA2 à deux disques sur un contrôleur LSI MegaRAID. Le serveur a également obtenu 24 Go de mémoire.

Nous devons refléter notre dernière sauvegarde téléchargée avec un débit maximal.

Le RAID0 pour nos sauvegardes "à chaud" nous donne environ 260 Mo / sec en écriture et 275 Mo / sec en lecture. Un tmpfs testé avec une taille de 20 Go nous donne environ 1 Go / sec. Ce type de débit est ce dont nous avons besoin.

Maintenant, comment puis-je régler le sous-système de mémoire virtuelle de Linux pour mettre en cache les derniers fichiers téléchargés aussi longtemps que possible en mémoire sans les écrire sur le disque (ou encore mieux: écrire sur le disque ET les conserver en mémoire)?

J'ai installé les sysctls suivants, mais ils ne nous donnent pas le débit que nous attendons:

# VM pressure fixes
vm.swappiness = 20
vm.dirty_ratio = 70
vm.dirty_background_ratio = 30
vm.dirty_writeback_centisecs = 60000

Cela devrait en théorie nous donner 16 Go pour la mise en cache des E / S et attendre quelques minutes jusqu'à son écriture sur le disque. Pourtant, lorsque je teste le serveur, je ne vois aucun effet sur l'écriture, le débit n'augmente pas.

Besoin d'aide ou de conseils.

En regardant les variables que vous avez définies, il semble que vous soyez principalement préoccupé par les performances d'écriture et que vous ne vous souciez pas des pertes de données possibles dues à des pannes de courant.

Vous n'aurez que l'option pour les écritures paresseuses et l'utilisation d'un cache d'écriture différée avec des opérations d'écriture asynchrones. Les opérations d'écriture synchrone nécessitent une validation sur disque et ne seront jamais écrites paresseusement. Votre système de fichiers peut provoquer des vidages de page fréquents et des écritures synchrones (généralement en raison de la journalisation, en particulier avec ext3 en mode données = journal). De plus, même les vidages de page "d'arrière-plan" interféreront avec les lectures non mises en cache et les écritures synchrones , les ralentissant ainsi.

En général, vous devriez prendre quelques mesures pour voir ce qui se passe - voyez-vous votre processus de copie mis dans l'état "D" en attendant que le travail d'E / S soit effectué par pdflush? Voyez-vous une forte activité d'écriture synchrone sur vos disques?

Si tout le reste échoue, vous pouvez choisir de configurer un système de fichiers tmpfs explicite où vous copiez vos sauvegardes et synchronisez les données avec vos disques après coup - même en utilisant automatiquement inotify

Pour la mise en cache de lecture, les choses sont beaucoup plus simples - il y a l' fadviseutilitaire fcoretools qui a le --willneedparamètre pour conseiller au noyau de charger le contenu du fichier dans le cache de tampon.

Éditer:

vm.dirty_ratio = 70

Cela devrait en théorie nous donner 16 Go pour la mise en cache des E / S et attendre quelques minutes jusqu'à son écriture sur le disque.

Cela n'aurait pas grandement influencé votre scénario de test, mais votre compréhension est fausse. Le paramètre dirty_ratio n'est pas un pourcentage de la mémoire totale de votre système mais plutôt de la mémoire libre de votre système .

Il y a un article sur le réglage des charges lourdes en écriture avec des informations plus détaillées.

Ou obtenez simplement plus de disques ... La configuration de la baie de disques que vous avez ne prend pas en charge tout au long de votre configuration. Il s'agit d'un cas où la solution doit être repensée pour répondre à vos besoins réels. Je comprends que ce n'est qu'une sauvegarde, mais il est logique d'éviter une correction kludgy.

L'utilisation du cache de mémoire peut impliquer une perte de données car si quelque chose ne va pas, les données qui sont en mémoire et qui ne sont pas enregistrées sur les disques seront perdues.

Cela dit, il y a des réglages à faire au niveau du système de fichiers.

Par exemple, si vous utilisiez ext4, vous pouvez essayer l'option de montage:

barrière = 0

Cela: "désactive l'utilisation des barrières d'écriture dans le code jbd. Les barrières d'écriture imposent un bon ordre sur le disque des validations de journal, ce qui rend les caches d'écriture de disque volatiles sûrs à utiliser, avec une certaine pénalité de performance. Si vos disques sont sauvegardés par batterie dans un sens ou une autre, la désactivation des barrières peut améliorer les performances en toute sécurité. Les options de montage "barrière" et "nobarrier" peuvent également être utilisées pour activer ou désactiver les barrières, par souci de cohérence avec les autres options de montage ext4. "

Plus à: http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt