Engineering

Habt ihr Elasticsearch schon „getrimmt“?

Von
Dimitrios Liappis

July 9, 2018: Dieser Blog wurde aktualisiert, um Empfehlungen zu beinhalten, wann der TRIM-Befehl nicht genutzt werden sollte, um die Produktionsumgebung nicht zu verlangsamen.

Bei Elastic führen wir regelmäßig Benchmarks durch, um die Performance von Elasticsearch zu überprüfen. Die Ergebnisse sind öffentlich verfügbar. Dabei ist uns aufgefallen, dass es immer wieder zu einem Leistungsabfall kommt, der einem bestimmten Muster folgt:

recurring-elasticsearch-slowness

Die vorangehende Grafik zeigt eine Spitzen-Performance am 26.09.2016, die in der Folge schrittweise abfällt, sich dann am 03.10.2016 wieder erholt und anschließend erneut stetig abfällt, bevor sie sich am 10.10.2016 wieder erholt. Hast du das Muster erkannt? DatumWochentag20160926Montag20161003Montag Dass es sich dabei um die Auswirkungen periodischer astronomischer Erscheinungen handelt, schien uns eher unwahrscheinlich. Stattdessen haben wir die im Betriebssystem geplanten wöchentlichen Aufgaben unter die Lupe genommen.

Unsere Benchmarks laufen auf Bare-Metal-Servern. Dabei werden zwei SSD-Festplatten mit Software-Raid-0-Konfiguration und Ubuntu 16.04 verwendet.

Hier seht ihr den cron.weekly-Eintrag einer auf Ubuntu Server 16.04 LTS basierenden virtuellen Maschine. Zu beachten ist dabei vor allem der fstrim-Befehl.

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

TRIM – was soll das denn bitte sein?

Auf Wikipedia wird es folgendermaßen erklärt:

TRIM ist ein Befehl zur Markierung ungenutzter oder ungültiger Datenblöcke auf Speichermedien, um sie später wieder beschreiben zu können. Der TRIM-Befehl ermöglicht es dem Betriebssystem einem Solid-State-Drive (SSD) mitzuteilen, dass gelöschte oder anderweitig freigewordene Blöcke nicht mehr benutzt werden.

SSD-Festplatten bestehen aus Gruppen von Flash-(NAND)-Speicherzellen. Im Vergleich zu klassischen, magnetischen Festplatten weisen SSD-Speicher drei Hauptunterschiede auf, die ihre Performance beeinträchtigen können:

  1. Speicherzellen lassen sich nicht direkt überschreiben, sondern vorhandene Daten müssen erst gelöscht werden, bevor sie durch neue Daten ersetzt werden können.
  2. Speicherzellen unterstützen nur eine begrenzte Anzahl von Löschzyklen und können daher nicht beliebig oft neu beschrieben werden.
  3. Speicherzellen sind in Pages und Blöcken angeordnet und können nur blockweise gelöscht werden!

Hersteller haben auf diese Einschränkungen reagiert, indem sie eine Funktion namens „Garbage Collection“ integrieren. Blöcke, die sowohl Pages mit Daten als auch Pages enthalten, die als löschbar markiert wurden, werden geleert, nachdem die mit Daten gefüllten Pages zunächst in freie Blöcke kopiert wurden. Deswegen generieren SSD-Festplatten intern mehr Schreiboperationen, als eigentlich erforderlich wäre; dieses Phänomen bezeichnet man als Write Amplification.

Wenn das Betriebssystem den Befehl zum Löschen einer Datei erhält, aktualisiert das Dateisystem lediglich die Metadaten. Die Festplattenadressen, wo sich die eigentlichen Daten befinden, werden hingegen nicht gelöscht. Dadurch verschlimmert sich die Write Amplification auf SSD-Festplatten, während die Garbage Collection läuft.

Dieses Problem lässt sich lösen, indem das Betriebssystem einen TRIM-Befehl ausführt, der dem SSD-Laufwerk mitteilt, welche Daten gelöscht sind. Das hat gleich zwei Vorteile:

  • Ihr vermeidet unnötige Datenbewegungen (von Daten, die bereits vom Betriebssystem gelöscht wurden) während der Garbage Collection.
  • Die Effizienz der Garbage Collection wird verbessert, weil mehr freier Speicherplatz verfügbar ist.

Was bedeutet das in der Praxis

SSD-Festplatten laufen schneller, wenn das Dateisystem ihnen Bescheid sagt, welche Dateien gelöscht wurden. Genau dafür sorgt der crontab-Befehl fstrim auf Ubuntu.

Macht das wirklich einen so großen Unterschied?

Und wie! Seit der cron-Befehl fstrim täglich ausgeführt wird (ab 17.10.2016), hat sich die oben erwähnte Kurve stabilisiert, wie in dieser Grafik zu erkennen ist:

elasticsearch-performance-after-trim

Welche nachteiligen Auswirkungen es hat, wenn TRIM nicht aktiviert ist, zeigt die folgende Grafik. Zu sehen sind die Ergebnisse von zehn aufeinanderfolgenden Testläufen mit einem anderen Benchmark (PMC). Dabei wurde das Dateisystem nur einmal geTRIMmt, und zwar unmittelbar vor dem ersten Testlauf.

ten-rally-benchmark-iterations-notrim

Gibt es einen Grund, TRIM nicht zu nutzen?

Während das Kürzen von Festplatten vor dem Ausführen von Benchmarks sinnvoll ist (als ein Beispiel), kann es Gründe geben, warum Sie dies in Produktionsumgebungen nicht möchten.

Abhängig davon, wann der TRIM-Befehl gegeben wurde, kann sich die Leistung während der Ausführung des Befehls erheblich verschlechtern und dieser kann lange dauern.

  • Bei Elastic Cloud Enterprise (ECE) Installationen kann die Steuerebene bei längeren Anpassungen mit systemweiten Auswirkungen instabil werden. Aus diesem Grund wird empfohlen, den manuellen TRIM von ECE-Datenträgern zu vermeiden.
  • In anderen Produktionsfällen wird dringend empfohlen, die Ausführung nur während eines ruhigen Zeitraums zu planen oder den TRIM-Befehl vollständig zu deaktivieren, sollte es keinen ruhigen Zeitraum geben.

Aber Vorsicht

Auf CentOS-7 ist das fstrim.service und der damit verbundene Systemd-Timer standardmäßig deaktiviert. Man muss das Service also zunächst aktivieren und wahrscheinlich auch den voreingestellten Zeitplan überschreiben.

Wenn ihr mit LVM arbeitet und regelmäßig Größenänderungen durchführt, müsst ihr issue_discards in /etc/lvm/lvm.conf auf 1 setzen. Wer unter Linux zur Verschlüsselung dm-crypt nutzt, sollte unbedingt die Anweisungen zur Konfiguration von TRIM unter lvm/dm-crypt auf der Wiki-Seite von ArchLinux beachten.

Für Cloud-Instanzen, die direkten Zugriff auf SSD-Speicher bieten, gelten die Hinweise zu TRIM ebenfalls. Betroffen sind Linux-AMIs einiger Amazon-Instanzen, die Instance-Store verwenden.

Fazit

Elasticsearch ist eine datenintensive Anwendung. Wenn ihr sie auf einem SSD-Speicher installiert habt, solltet ihr überprüfen, ob TRIM aktiviert ist und – je nach Datenlast – gegebenenfalls die Häufigkeit des Trimmens ändern. Ihr werdet staunen, wie viel Performance das bringt!