- Netflix migrierte einen CPU-lastigen Java-Microservice von m5.4xl (16 vCPU) auf m5.12xl (48 vCPU)
- Da die Zahl der vCPUs dreimal so hoch war, wurde ungefähr eine dreifache Leistungssteigerung erwartet, doch der Durchsatz stieg nur um 25 %
- Außerdem sank die Latenz sogar um 50 %, und sowohl CPU- als auch Latenzmuster wurden deutlich „abgehackter“ (choppy)
- Ein Artikel, der den Weg zur Lösung bis auf Low-Level-Ebene zusammenfasst
Lösungsweg
- Zunächst wurden schnelle und langsame Nodes miteinander verglichen
- Mit Flame Graphs und JVM-Profiling (unter Verwendung von JFR – Java Flight Recorder) ließ sich kein Unterschied erkennen
- Da es auf App-/OS-/JVM-Ebene nichts Auffälliges gab, wurden die PMC (Performance Monitoring Counters, PMU Counter) untersucht, die von der m5.12xl-Instanz bereitgestellt werden
- Eines der Probleme war „False Sharing“ – ein Muster, das entsteht, wenn zwei Kerne unabhängige Variablen lesen oder schreiben, die sich dieselbe L1-Cache-Zeile teilen
- Im JDK-Code wurde dieses Problem gelöst, ohne die Funktionalität zu ändern, indem Padding-Bytes eingefügt wurden, die nur das Datenlayout verändern
- Ein weiteres Problem war „True Sharing“ – wenn mehrere Threads/Kerne dieselbe Variable lesen und schreiben
- Um das zu beheben, wurde nicht mehr in die gemeinsame Variable geschrieben und stattdessen der Secondary-Superclass-Cache der JVM umgangen
- Nachdem beide Probleme gepatcht waren, war das System 3,5-mal schneller als zuvor
- Während der Lösung dieses Problems wurde außerdem der seit fünf Jahren ruhende Bug JDK-8180450 entdeckt
Fazit
- Es besteht die Tendenz, die JVM als hochoptimierte Runtime-Umgebung zu betrachten, die mit performanceorientierten Sprachen wie C++ konkurriert
- Für die meisten Workloads trifft das zu, doch bei bestimmten Workloads kann nicht nur die Implementierung der Anwendung, sondern auch die Implementierung der JVM selbst Einfluss haben
- In diesem Fall wurden PMC verwendet, um einen Bottleneck im nativen Code der JVM zu finden und zu patchen, wodurch der Durchsatz dieses Workloads um mehr als das Dreifache verbessert wurde
- Bei dieser Art von Performance-Problemen ist die Fähigkeit, die Ausführung auf Ebene der CPU-Mikroarchitektur zu untersuchen, die einzige Lösung
- Intel vTune liefert selbst mit den zentralen PMC, die auf Instanzen wie m5.12xl sichtbar sind, wertvolle Einblicke
- Würden alle Cloud-Instanzen zusammen mit PEBS (Processor Event-Based Sampling) einen umfassenden PMC-Satz bereitstellen, wären durch tiefergehende Analysen noch deutlich größere Performance-Gewinne möglich
2 Kommentare
Wow, was zum …
Es muss ein großartiges Gefühl gewesen sein, als sich die Hypothese bestätigt hat und der Fehler behoben wurde.