Brendan Gregg, einer der Entwickler von DTrace, der derzeit BPF-basierte Leistungsanalysetools im Linux-Kernel entwickelt, fasste die Erfahrungen aus der Analyse der Leistungsprobleme zusammen, auf die Netflix bei der Migration des Cassandra-DBMS von CentOS auf Ubuntu-Umgebungen gestoßen ist die Amazon EC2 Cloud auf Basis von Xen. Nach der Migration erhöhte sich die CPU-Last um 30 % und die Verzögerungen bei Schreibvorgängen stiegen in etwa im gleichen Maße. Wie sich herausstellt, hängt die Leistung von Anwendungen, die intensiv Zeitinformationen anfordern, stark von der genauen Zeitquelle ab, die im System ausgewählt wird.
Der Grund für den Leistungsabfall war zunächst nicht offensichtlich und die Diagnose begann mit der Überwachung der möglichen Auswirkungen ständig laufender oder periodisch gestarteter ressourcenintensiver Systemprozesse mithilfe der Dienstprogramme top und execsnoop. Aber alles deutete darauf hin, dass der Ressourcenverbrauch insbesondere im in Java geschriebenen Cassandra-DBMS gestiegen war. Der Vergleich der Profilierungsmetriken zweier Cassandra-Prozesse, die parallel unter CentOS und Ubuntu laufen und dieselben Abfragen verarbeiten, zeigte, dass etwa 32 % der Gesamtzeit für den Aufruf von os::javaTimeMillis() aufgewendet wurden, der zum Abrufen von Informationen über die aktuelle Zeit verwendet wird .
Anschließend wurde ein Experiment durchgeführt, bei dem eine einfache Java-Anwendung geschrieben wurde, die die Methode System.currentTimeMillis() hundert Millionen Mal in einer Schleife aufrief. Das Ausführen der Anwendung zeigte, dass die Fertigstellung unter CentOS 13 Sekunden und unter Ubuntu etwa 68 Sekunden dauerte, d. h. 5-mal langsamer. Ein ähnliches Programm wurde in C geschrieben, das die Funktion gettimeofday() hundert Millionen Mal aufrief, aber bei der Ausführung wurden ähnliche Ergebnisse erzielt.
Da klar wurde, dass die Ursache des Problems in der Funktion der Rückgabe der aktuellen Zeit lag, richtete sich die Aufmerksamkeit auf Änderungen der Indikatoren bei der Auswahl verschiedener Quellen für die genaue Zeit im System. Dem Inhalt von „/sys/devices/system/clocksource/clocksource0/current_clocksource“ nach zu urteilen, wurde der „xen“-Timer standardmäßig verwendet, wenn Linux im Gastsystem ausgeführt wurde. Nach der Umstellung der Zeitquelle auf „tsc“ verringerte sich die Ausführungszeit der Testanwendung in Ubuntu von 68 auf 3.3 Sekunden, d.h. es wurde 20-mal schneller. Zusätzlich wurde ein Leistungstest der Zeitquelle kvm-clock durchgeführt, der einen Anstieg der Verzögerungen um 20 % im Vergleich zu TSC zeigte. $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ time java TimeBench real 1m8.300s Benutzer 0m38.337s sys 0m29.875s $ echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ time java TimeBench real 0m3.370s user 0m3.353s sys 0m0.026s
Um die Zeit bei der Auswahl einer TSC-Quelle zu erhalten, wird der RDTSC-Prozessorbefehl verwendet, für dessen Ausführung kein Systemaufruf erforderlich ist (der Befehl erfordert keine erhöhten Berechtigungen und erzeugt einen Wert aus dem in der CPU integrierten Zeitzähler). Standardmäßig ist TSC nicht aktiviert, da diese Quelle früher eine allmähliche Zeitabweichung nicht ausschloss, die bei anderen Prozessoren per Software angepasst wird, um genauere Messwerte zu erzielen. Laut einem auf Prozessorentwicklung spezialisierten Ingenieur sind Befürchtungen über Zeitverschiebungen bei der Verwendung von TSC schon lange unbegründet und bei modernen Prozessoren kann diese Quelle über Jahre hinweg stabile Messwerte liefern.
Die Umstellung der Produktionsserver bei Netflix auf eine TSC-Quelle führte zu einer Reduzierung der Schreiblatenz um 43 % und erzielte mit Ubuntu Ergebnisse, die viermal schneller waren als Konfigurationen, auf denen CentOS mit einer „Xen“-Zeitquelle ausgeführt wurde. Die Ergebnisse der Studie wurden an Amazon übermittelt, das offiziell die Verwendung der standardmäßigen TSC-Zeitquelle in AWS EC4-Umgebungen auf Basis des Xen-Hypervisors empfahl (kvm-clock bleibt in Umgebungen auf Basis des Nitro-Hypervisors empfohlen).
Source: opennet.ru