Est-ce que votre Elasticsearch est « trimmé » ?

9 Juillet 2018 : Cet article a été mis à jour pour ajouter des recommendations sur quand il ne faut pas "trimmer" les disques afin d'éviter des ralentissements majeurs en production.

Chez Elastic, nous évaluons régulièrement la performance d'Elasticsearch. Les résultats de ces évaluations sont disponibles publiquement. En s'intéressant aux résultats, nous avons observé une tendance récurrente de la dégradation de cette performance :

Sur l'image ci-dessus, on remarque un pic de performance le 26/09/2016 suivi d'une chute et d'une hausse à nouveau le 03/10/2016, puis une nouvelle baisse de performance avant la reprise du 10/10/2016. Avez-vous déjà remarqué cette tendance ?

| Date | Jour | | ---- | --------------- | | 20160926 | Lundi | | 20161003 | Lundi | | 20161010 | Lundi |

En mettant de côté l'influence possible des effets réguliers des astres, nous nous sommes plutôt intéressés aux tâches hebdomadaires programmées sur le système d'exploitation pour trouver une réponse.

Nos évaluations de référence se font sur des serveurs bare metal, utilisent deux SSD dans une configuration RAID-0 et ont Ubuntu 16.04 d'installé.

Vous trouverez ci-dessous le contenu du cron.weekly d'une VM basée sur un serveur Ubuntu 16.04 LTS. Regardez la tâche fstrim job.

vagrant@ubuntu1604vbox:/etc/cron.weekly$ ls
fstrim  man-db

Mais qu'est-ce donc que le TRIM ?

Selon cet article Wikipedia :

Une commande TRIM (TRIM dans les commandes ATA et UNMAP dans les commandes SCSI) permet au système d'exploitation d'indiquer au disque SSD quels blocs de données ne sont plus utilisés et peuvent être effacés en interne.

Les disques SSD sont composés de groupes de cellules de mémoire Flash (NAND). Les SSD présentent trois différences majeures avec les disques magnétiques traditionnels. Ces différences peuvent affecter la performance des disques SSD :

1. Les cellules de mémoire ne peuvent être écrasées en une seule opération : les données existantes doivent être d'abord effacées avant d'être remplacées par de nouvelles données.
2. Ces cellules ne supportent qu'un nombre limité de cycles écriture/effacement.
3. Les cellules de mémoire sont organisées en pages et en blocs, et les disques SSD ne peuvent effacer que des blocs en entier !

Ces limites ont forcé les fabricants à mettre en place ce qu'on appelle le Garbage Collection grâce auquel des blocs contenant à la fois des pages de données et des pages devant être supprimées sont effacés après que les pages de données aient été copiées dans des blocs vides. Par conséquent, les SSD créent en interne davantage d'entrées/sorties que ce que le système d'exploitation génère de façon explicite pour les opérations d'écriture. C'est ce qu'on appelle l'amplification de l'écriture.

Lorsque le système d'exploitation reçoit une requête pour supprimer un fichier, le filesystem ne met à jour que les métadonnées et n'efface pas les adresses du disque qui contiennent les vraies données. Cela aggrave le phénomène d'amplification de l'écriture des disques SSD lors de l'exécution du Garbage Collector. Pour résoudre ce problème, les systèmes d'exploitation peuvent émettre la commande TRIM pour informer le disque SSD des données effacées. Deux avantages en découlent :

• cela évite les mouvements de données inutiles (des données déjà supprimées par le système d'exploitation) lors de l'exécution du Garbage Collector, et
• cela améliore l'efficacité du Garbage Collector car il y a davantage d'espace disponible.

En pratique, qu'est-ce que cela signifie ?

Vos SSD fonctionneront plus rapidement si le filesystem leur transmet des informations sur les fichiers déjà supprimés. Voilà à quoi sert le processus en crontab fstrim sur Ubuntu.

Voit-on vraiment la différence ?

Oh que oui ! Lorsque l'on programme la tâche cron fstrim (après le 17/10/2016) sur une base quotidienne, on peut voir que le graphique précédent se stabilise :

L'effet négatif de ne pas avoir mis en place le TRIM peut être constaté sur dix exécutions consécutives du benchmark (PMC). Le filesystem a appliqué la commande TRIM une seule fois, avant de lancer l'évaluation :

Existe-t'il une raison pour ne pas "trimmer" ?

Alors que lancer un TRIM des disques avant l'exécution de benchmarks peut être logique, il y des raisons éventuelles pour ne pas le faire en production.

En fonction de quand les disques ont été ajustés la dernière fois, les performances peuvent être sévèrement dégradées pendant le TRIM et cette opération peut prendre un très long moment avant de s'achever.

• Pour les installations d'Elastic Cloud Enterprise (ECE), le "control plane" peut devenir instable pendant l'exécution du long TRIM avec des répercussions systèmes importantes. Par conséquent, nous recommandons de ne pas lancer de TRIM manuellement sur ECE.
• Pour les autres cas de production, il est fortement recommandé de planifier l'exécution du TRIM pendant une période creuse d'activité ou si aucune période calme n'existe de complètement désactiver le TRIM périodique.

Caveats

Sur CentOS-7, le fstrim.service et le timer systemd associé sont désactivés par défaut, vous devrez donc activer le service et probablement remplacer le programme du timer par défaut.

Si vous utilisez LVM et que vous effectuez souvent des opérations de redimensionnement, vous devrez régler issue_discards sur 1 dans /etc/lvm/lvm.conf.

La couche de chiffrement de Linux, dm-crypt, si vous l'utilisez, doit être configurée de manière spécifique. Vous trouverez les instructions pour la configuration de TRIM sous lvm/dm-crypt sur la page wiki d'ArchLinux.

Ce problème de TRIM affecte également les instances dans le cloud si elles fournissent un accès direct aux SSD. C'est le cas pour les AMI Linux basées sur le stockage d'instance de certaines instances d'Amazon.

Conclusion

Elasticsearch est une application gourmande en IO (entrées/sorties). Si vous l'exécutez sur un SSD, vérifiez que vous avez activé TRIM et, en fonction de la charge, ajustez la fréquence de la tâche Trim. Vous serez étonné des améliorations de performances !