Forte activité d'écriture sur les performances du système de disques SSD

J'ai remarqué que lorsque je fais des applications d'écriture lourdes, tout le système ralentit. Pour tester cela plus loin, je l'ai exécuté pour faire une activité de disque (relativement) faible en CPU et haute:

john -incremental > file_on_SSD

Cela pompe des dizaines de milliers de chaînes par seconde dans un fichier sur mon disque système.

Dans ce cas, la souris est à la traîne, les ATS ne répondent plus, les applications "s'estompent" et généralement tout l'ordinateur devient inutilisable. Quand je pourrai finalement contrôler + C john, le système reviendra à sa pleine puissance après quelques secondes.

Ceci est un exemple extrême mais j'ai des problèmes similaires avec des activités un peu moins intensives en écriture comme la copie de gros fichiers à partir de sources rapides ou le transcodage.

Mon disque OS principal est un SSD assez rapide ( OCZ Agility 60GB ) avec EXT4. Si j'écris johnla sortie sur un disque mécanique avec EXT4, je ne connais pas les mêmes ralentissements bien que le taux soit beaucoup plus lent (le SSD fait ~ 42 000 mots par seconde, le mécanique fait 8 000 w / s). Le débit peut être pertinent. Le disque mécanique n'a également rien à voir avec le système. Ce ne sont que des données.

Et j'utilise le noyau 2.6.35-2 mais j'ai remarqué ce problème depuis que j'ai obtenu ce SSD alors que j'utilisais probablement .31 ou quelque chose de cette époque.

Alors, quelle est la cause du ralentissement? Problème EXT4? Problème de noyau? Problème de SSD? Tout ce qui précède? Autre chose?

Si vous pensez que je dois effectuer un test supplémentaire, laissez simplement un commentaire me dire quoi faire et j'ajouterai le résultat à la question.

Cela a été un problème connu depuis un certain temps. L'utilisation d'un FS réglé sur SSD comme Btrfs peut aider, mais ce n'est pas le cas.

En fin de compte, c'est un bogue dans les systèmes de gestion de mémoire / planificateur IO. Récemment, il y a eu quelques correctifs qui visent à résoudre ce problème. Voir Corrigé: Le problème de réactivité du bureau Linux?

Ces correctifs peuvent éventuellement faire leur chemin dans le noyau principal, mais pour l'instant, vous devrez probablement compiler votre propre noyau si vous souhaitez résoudre ce problème.

Il y a quelques choses que vous pouvez vérifier pour essayer d'améliorer les performances SSD sous Linux.

1. Réglez le point de montage sur «noatime». Une activité supplémentaire mettant à jour les temps d'accès est généralement gaspillée dans la plupart des cas d'utilisation. Surtout dans le cas du pompage continu de lignes uniques dans un fichier, vous forcez plusieurs mises à jour du système de fichiers pour chaque accès.

2. Vérifiez l'ascenseur. L'ascenseur par défaut pour la plupart des distributions est configuré pour les plateaux tournants à accès aléatoire. Les disques SSD n'ont pas besoin de la logique supplémentaire, donc régler l'ascenseur sur noop peut améliorer les performances en laissant le matériel gérer les écritures.

3. Mise en cache en écriture différée ou réécriture C'est un peu plus ésotérique, mais vous pouvez vérifier la méthode de mise en cache utilisée avec hdparmpour l'appareil. La mise en cache en écriture différée peut avoir un impact positif sur les performances du SSD par rapport à l'écriture directe.

La mise en cache de vos fichiers est probablement mal réglée pour votre charge de travail. Malheureusement, le noyau Linux est suffisamment stupide pour ne pas gérer cela automatiquement et les valeurs par défaut sont assez mauvaises si vous avez beaucoup de RAM et des blocs suffisamment lents. Voir https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/ pour plus de détails.

Je suggère d'essayer de modifier /etc/sysctl.confsoit

vm.dirty_background_ratio = 3
vm.dirty_ratio = 6

pour réduire fortement la pression RAM causée par la mise en cache de l'écriture pour permettre au noyau de mieux gérer les autres tâches. Cela permettra d'échanger une latence améliorée contre un débit inférieur.

Une autre possibilité consiste à augmenter la mise en cache, mais si votre processus écrit constamment de nouvelles données tout le temps, vous obtiendrez une très mauvaise latence si le cache est saturé. Si vous voulez l'essayer, vous pouvez faire quelque chose comme

vm.dirty_background_ratio = 5
vm.dirty_ratio = 80

Notez que les *_ratioparamètres se réfèrent au pourcentage de RAM disponible. Si vous souhaitez un meilleur contrôle, utilisez les *_bytesparamètres. J'utilise personnellement la configuration suivante pour mon poste de travail:

vm.dirty_background_bytes = 50000000
vm.dirty_bytes = 200000000

Cela limite le cache d'écriture en arrière-plan à 50 Mo et force l'écriture syncrone si 200 Mo se trouvent dans le cache.