Profilierung in der Produktion: wohin die CPU tatsächlich geht

Hier ist eine bekannte Situation. Ein Dashboard zeigt einen Dienst, der viel mehr CPU verwendet, als er sollte. Die Latenz nimmt zu. Sieh dir die Kennzahlen an: Ja, die CPU ist hoch. Sie sehen sich die Spuren an: Anfragen sind langsam, aber innerhalb des Dienstes, nicht in seinen Abhängigkeiten. Sieh dir die Protokolle an: nichts Ungewöhnliches.

Was Sie wirklich wissen wollen ist: Welcher Code Verbraucht die ganze CPU? Das ist, was Profiling Antworten. Und die kontinuierliche Profilung beantwortet das die ganze Zeit, in der Produktion.

Was die Profilung zeigt

A Profil Aufzeichnungen, in denen ein Programm seine Ressourcen aufwendet, bis hin zu einzelnen Funktionen und Zeilen:

• Profile der CPU: welche Funktionen auf der CPU ausgeführt werden und wie viel.
• Profile für Speicher (Heap): welcher Code den Speicher zuweist und wie viel noch gespeichert ist.
• Zuweisungsprofile: wie oft Speicher zugewiesen wird, was die Müllentsammlung überfordert.
• Profile für Schloss- und Goroutine-/DrehprofileWo der Code wartet.

Die Profile werden in der Regel wie folgt dargestellt: Flammendiagramme: jede Balke ist eine Funktion, ihre Breite zeigt, wie lange es dauerte, und Funktionen, die sie aufgerufen hat, sind oben gestapelt. Breite Balken sind, wo die Zeit vergeht. Sie können auf einen Blick sehen, dass zum Beispiel 30% der CPU in JSON-Serialisierung gehen, oder ein Regex wird bei jeder Anfrage kompiliert.

Die Messwerte sagen, dass Ihr Service langsam ist. Ein Flammendiagramm zeigt auf die Codezeile, die es langsam macht.

Warum die Profilung fortgesetzt wird

Entwickler haben seit Jahrzehnten Code profiliert, aber normalerweise lokal, für ein paar Minuten, mit speziellen Tools. Das Problem: Die Produktion verhält sich anders. Unterschiedliche Daten, unterschiedlicher Verkehr, unterschiedliche Last.

Kontinuierliche Profilung Profile aus der Produktion ständig sammeln, mit geringen Overheadkosten, und speichern, damit Sie:

• Schauen Sie sich einen beliebigen Punkt in der Vergangenheit an: "Was hat dieser Dienst während des gestrigen Spikes gemacht?"
• Vergleichen Zeiträume oder Versionen: "Was hat sich in der CPU-Nutzung nach der Version 2.4 geändert?"
• Sieh die ganze Flotte an, nicht nur eine Instanz.
• Verknüpfen Sie Profile mit Spuren, so dass eine langsame Spanne genau zeigt, welcher Code ausgeführt wurde.

Die Werkzeuge

• Grafana Pyroskop: Open Source, integriert sich mit Grafana, unterstützt viele Sprachen über SDKs und eBPF.
• Parca: Open Source, eBPF-basiert, profiliert alles auf einem Knoten ohne Codeänderungen.
• Profilierung in der OpenTelemetry: Profile werden zum vierten OpenTelemetry-Signal, wobei ein eBPF-basierter Profiling-Agent dem Projekt gespendet wurde. Noch nicht reif, aber es ist klar, wohin die Dinge gehen.
• Handelszwecke: Datadog, Elastic, Google Cloud Profiler, Polar Signals und andere.

Es gibt zwei Möglichkeiten, die Einnahmen zu sammeln:

• auf eBPF-Basis: ein Agent auf jedem Knoten profiliert jeden Prozess, in jeder Sprache, ohne Codeänderungen. Leicht zu verbreiten. Beste Unterstützung für kompilierte Sprachen und wachsende Unterstützung für interpretierte Sprachen.
• SDK-basiert: eine Bibliothek in Ihrer Bewerbung. Gibt reichere Informationen für einige Laufzeiten (wie Speicherprofile in Go oder Java), zu Lasten der Hinzufügung einer Abhängigkeit.

Die Gemeinkosten

Die übliche erste Frage: verlangsamt die Profilisierung die Produktion? Moderne kontinuierliche Profiler sammeln, indem sie zum Beispiel den Stapel hundertmal pro Sekunde betrachten, anstatt jeden Funktionsanruf zu verfolgen. Der Overhead ist in der Regel gering, oft etwa 1% der CPU, abhängig vom Tool und den Einstellungen.

Verglichen mit den Einsparungen, die es oft findet, ist das ein sehr gutes Geschäft. Aber testen Sie es auf Ihren Arbeitslasten und beginnen Sie mit ein paar Diensten.

Wie Profiling die CPU-Kosten senkt

Hier lohnt sich die kontinuierliche Profilbildung. Häufige Erkenntnisse, wenn sich Teams erstmals Flotten-Flammengraphen ansehen:

• Teure Holzfällungen: Zeichenfolgeformatierung und Serialisierung für Debug-Logs, die nie ausgeliefert werden.
• Ineffiziente Serialisierung: JSON-Codierung und -Decodierung, die die CPU in API-Diensten dominiert.
• Wiederholt kompilierte Regexen statt einmal.
• Unnötige Mittelzuweisungen Die Abfallentsorgung ist sehr hoch.
• Schwatzige Bibliotheken: ein HTTP-Client oder ORM, der viel mehr Arbeit leistet als erwartet.
• Warmschleife In Code, den seit Jahren niemand mehr anschaut.

Ein einziges breites Balken in der Flammengrafik eines Dienstes, der auf Hunderten von Kernen läuft, zu fixieren, kann echtes Geld sparen. Deshalb ist Profiling immer mehr Teil von FinOps-Gesprächen, nicht nur Leistungs-Tuning.

Ein einfacher Weg, um zu beginnen

1. Ein eBPF-basierter Profiler (Pyroskop-Mittel, Parca oder OTel-Profiling) wird auf einem Testcluster installiert.
2. Öffnen Sie die Flammen-Grafik für Ihren CPU-hungrigsten Dienst.
3. Suchen Sie nach den breitesten Balken, die nicht Ihre Kernlogik sind.
4. Wählen Sie eine, reparieren Sie sie, setzen Sie sie ein und Vergleichen Vorher und danach.

Dieser erste Vergleich, eine sichtbar schmalere Stange und ein niedrigeres CPU-Grafiken, ist in der Regel das, was den Rest des Teams überzeugt.

Also, ist es das wert?

Für jedes Team, das Dienstleistungen in großem Maßstab betreibt, ja. Kontinuierliches Profiling füllt die Lücke zwischen "der Service ist langsam" und "hier ist der Grund", und es findet regelmäßig Einsparungen, die für den gesamten Beobachtungsstapel bezahlen.

Meine Meinung: Rate nicht, wohin deine CPU geht. Sieh mal. Die Flammen-Grafik ist normalerweise ehrlicher als wir alle.

Desly