Linux-Performance

 (brendangregg.com)
3 Punkte von GN⁺ 2023-10-15 | 1 Kommentare | Auf WhatsApp teilen
  • Brendan Greggs Linux-Performance-Seite ist ein Link-Hub, der die für den Einstieg in die Untersuchung der Linux-Performance nötigen Materialien zu Observability, Analyse, Benchmarking und Tuning an einem Ort bündelt
  • Der zentrale Werkzeug-Workflow verläuft über perf, eBPF, bcc, bpftrace, Flame Graphs; von Befehlsbeispielen bis hin zu Tracing-Tools und Visualisierung lässt sich alles direkt aufrufen
  • Die Dokumentationsmaterialien reichen von Netflix’ Performance-Analyse-Artikel aus dem Jahr 2015 über EC2-Tuning, Linux load averages, frame pointers und gdb-Beispiele bis hin zu zwei Performance-Büchern
  • Die Vortragsliste bietet situationsbezogene Lernpfade wie eine 40-Minuten-Übersicht, ein 90-Minuten-Tool-Tutorial, Container-Performance-Analyse und eine SRE-Checkliste
  • Bei jeder Tool-Map sollte die Aktualität über das Jahr unten rechts im Bild geprüft werden; das integrierte Diagramm ist nicht so vollständig wie die anderen Einzelgrafiken

Hub für Performance-Materialien und Tool-Maps

  • Diese Seite ist ein Link-Hub mit von Brendan Gregg zusammengestellten Linux-Performance-Materialien
  • Die Tool-Map-Grafik rechts wurde mit großer Schrift für Foliensätze erstellt und ist in einem Format gehalten, das man ausdrucken und an die Bürowand hängen kann
  • Die Tool-Maps gliedern Linux-Performance-Arbeit in die folgenden Bereiche
  • Wie aktuell die einzelnen Bilder sind, sollte über das Jahr unten rechts geprüft werden
  • Ein hochauflösendes Diagramm, das Observability, statisches Performance-Tuning und perf-tools/bcc zusammenführt, wird ebenfalls separat angeboten
    • png
    • svg
    • Dieses integrierte Diagramm ist nicht so vollständig wie die anderen Einzelgrafiken

Direkt verlinkte Hauptwerkzeuge

  • perf: perf one-liners, Beispiele und Visualisierungsmaterialien
  • eBPF tools: BPF/bcc-Tracing-Tools und Beispiele
  • perf-tools: Ftrace-basierte perf-Werkzeugsammlung
  • bcc: Sammlung von BPF/bcc-Performance-Tools
  • bpftrace: Sammlung von BPF/bpftrace-Performance-Tools
  • Flame Graphs: Verwendung von Flame Graphs mit perf und anderen Profilern

Dokumentation und Lernmaterialien

Vertiefende Artikel zu eBPF, ftrace und perf

Empfohlene Vorträge nach Situation

  • Linux Systems Performance, USENIX LISA 2019

    • Fasst in 40 Minuten die Linux-System-Performance unter sechs Aspekten zusammen: Observability, Methodik, Benchmarking, Profiling, Tracing und Tuning
    • video, youtube, slides, PDF

  • Linux Performance 2018, PerconaLive 2018

    • Fasst die aktuellen Änderungen und Funktionen der Linux-Performance im Jahr 2018 in einer 20-minütigen Keynote zusammen
    • youtube, slideshare, PDF

  • Linux Performance Tools, Velocity 2015

    • Ein 90-minütiges Tutorial zu Performance-Observability, Benchmarking, Tuning, statischem Performance-Tuning, Tracing-Tools und -Methoden sowie Live-Demos
    • youtube playlist, slideshare, PDF

  • How Netflix Tunes EC2 Instances for Performance, AWS re:Invent 2017

    • Legt den Fokus stärker auf Tuning als auf Performance-Observability und behandelt den Netflix-Hintergrund, AWS-EC2-Instanztypen und -Features, Linux-kernel tunables sowie Observability
    • youtube, slideshare

  • Container Performance Analysis, DockerCon 2017

    • Behandelt, wie man Engpässe im Host oder Container findet, Container-Apps profiliert und tiefer bis in den Kernel vordringt
    • youtube, slideshare

  • Broken Linux Performance Tools, SCaLE14x 2016

    • Behandelt häufige Probleme bei Linux-System-Tools, Metriken, Statistiken, Visualisierung, Mess-Overhead und Benchmarks sowie Ratschläge im Abschnitt „What You Can Do“
    • youtube, slideshare, PDF

  • Using Linux perf at Netflix, Kernel Recipes 2017

    • Fokussiert auf CPU-Profiling und die Funktionsweise von Flame Graphs und behandelt Probleme mit Stack Traces und Symbols beim Profiling von perf_events-Eigenschaften sowie Java, Node.js, VMs und Containern
    • youtube, slideshare

  • Give me 15 minutes and I'll change your view of Linux tracing, LISA 2016

  • Performance analysis superpowers with Linux eBPF, O’Reilly Velocity 2017

    • Behandelt den Einsatz von enhanced BPF, also eBPF, das zur Linux-4.x-Serie hinzugefügt wurde, für Performance-Analyse, Observability und Debugging
    • Das Frontend ist das Open-Source-Projekt bcc, das die BPF-Schnittstelle und ein Toolset bereitstellt
    • youtube, slideshare, PDF

  • Linux Performance Analysis: New Tools and Old Secrets, LISA 2014

    • Behandelt die Tools ftrace und perf_events sowie perf-tools, das hauptsächlich ftrace verwendet
    • ftrace wird als Tracer vorgestellt, der seit vielen Jahren in den Linux-Kernel integriert ist, aber kaum entdeckt wurde
    • youtube, slideshare, PDF

  • Performance Checklists for SREs, SREcon 2016

    • Enthält im hinteren Teil eine Checkliste für Linux-Incident-Performance-Response und kann auch für dringende Linux-Performance-Analysen nützlich sein
    • youtube, usenix, slideshare, PDF

Externe Empfehlungen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-10-15
Hacker-News-Meinungen

  • Ich nutze tuned auf einem Debian/Ubuntu-VPS, auf dem Echtzeit-Apps laufen, und es funktioniert ziemlich gut.
    Es ist einfacher, als Kernel-Parameter, also sysctl-Einstellungen oder Kernel-Tunables, direkt zu ändern.
    https://access.redhat.com/documentation/en-us/red_hat_enterp...
    sudo apt install tuned

    • Wir verwenden Tuned auch für SAP-Workloads und sind sehr zufrieden damit.

  • Ich wusste gar nicht, dass Brendan Gregg inzwischen bei Intel ist.
    https://en.wikipedia.org/wiki/Brendan_Gregg
    Er ist auch die Hauptfigur des viralen Videos Shouting in the Data Center.
    https://www.youtube.com/watch?v=tDacjrSCeq4
    Ein echtes Genie.

  • Es ist erwähnenswert, dass es bei fast allem im Original nicht um Latenz geht, sondern um Durchsatz/Bandbreite von Netzwerk, Festplatte, sonstiger Ein-/Ausgabe und CPU.
    Für viele Leute bedeutet Performance eben Durchsatz, insofern verständlich. Es gibt aber auch Fälle, in denen Latenz viel wichtiger ist als Durchsatz, und um Latenz unter Linux zu tunen, braucht man ein anderes Set an Werkzeugen.

    • Ziemlich berechtigter Hinweis. Latenz zu senken ist außerdem deutlich schwieriger, als den Durchsatz zu erhöhen[1], deshalb ist es oft wichtig, auf Latenz zu achten.
      Eine weitere Achse, auf der man optimieren kann, ist Performance pro Watt, aber darauf gehe ich hier nicht weiter ein.
      Manchmal ist Durchsatzoptimierung zugleich Latenzoptimierung. Wenn man zum Beispiel mehr Prozesse auf eine Maschine packen kann, sinkt die durchschnittliche Entfernung zwischen Prozess und Kommunikationsziel, und damit auch die durchschnittliche Latenz.
      Beim Optimieren von Latenz ist es ein ganz naheliegender Schritt, den Durchsatz so weit zu erhöhen, dass er nicht zum Flaschenhals wird.
      Wenn man Latenz aggressiv optimiert, habe ich den Eindruck, dass es bei Linux selbst gar nicht so viele Tuning-Schrauben gibt. Ich kann mich irren, aber meist scheinen Core Pinning, tickless Ausführung, User-Space-Networking und hardwareseitige Anpassungen wie Seitengröße, SMT, Energiespareinstellungen und Hardwareauswahl im Mittelpunkt zu stehen.
      [1] https://pdfs.semanticscholar.org/bce7/5f78d340cac32dccd8631f...
    • Statt bandwidth ist throughput wohl die passendere Bezeichnung. Die Bedeutung ist ähnlich, aber der Gegensatz zwischen Durchsatz und Latenz wird schon seit Langem diskutiert.
      Manchmal kann man beides verbessern, meistens ist es aber ein Trade-off.
    • Mich würden empfehlenswerte Tools oder Materialien zum Thema Latenz-Tuning interessieren.
    • Wenn das Ziel ist, die Latenz für Echtzeiteigenschaften des Systems zu senken, wird man mit einer Standard-Linux-Distribution wahrscheinlich kein zufriedenstellendes System bekommen, egal wie viele Stellschrauben man dreht.

  • Warten ist auch eine gute Strategie.
    Seit Linux 6.5 versteht der Scheduler, dass es nicht unbedingt optimal ist, etwas auf einem anderen „Kern“ zu platzieren, wenn ein SMT-„Kern“ ausgelastet ist. Tatsächlich ähnelt das eher einem einzelnen Kern mit sehr niedrigen Kosten für Kontextwechsel.
    Dadurch sind stark parallele Aufgaben spürbar flotter geworden, und man sieht es auch in den CPU-Auslastungsdiagrammen.
    Wegen Cache-Kohärenz und NUMA-Problemen können die Ergebnisse unterschiedlich ausfallen.

    • Bei älteren Kerneln kann man schon durch Deaktivieren von SMT einen flotteren Eindruck erreichen, außerdem einige Seitenkanalangriffe verhindern und die Energieeffizienz erhöhen.

  • Verwandte Beiträge:
    Linux Performance - https://news.ycombinator.com/item?id=13498485 - Januar 2017, 64 Kommentare
    Linux Performance - https://news.ycombinator.com/item?id=8205057 - August 2014, 22 Kommentare

  • Wenn jemand einen tunable Parameter ändern will, aber nicht erklären kann, warum diese Änderung den gewünschten Effekt haben sollte und warum der Wert überhaupt so gesetzt ist, würde ich die Änderung in der Produktion nicht zulassen.
    Man könnte das „Chestertons tunable Parameter“ nennen.

    • Selbst wenn man einen hypothetischen Grund erklären kann: Kann man es nicht ohnehin außerhalb der Produktion benchmarken?

  • Angesichts von Brendans eBPF-Arbeit verstehe ich dieses Material eher als Weg, unterschiedliche Performance-Situationen einfacher zu überwachen und zu bewerten.
    Bei Anpassungen und Tuning gibt es Trade-offs, und oft geht die Optimierung einer Seite zulasten einer anderen.
    Nebenbei: btop war als All-in-one-TUI-Viewer für Systemperformance und Last ein sehr nützlicher Ersatz für glances. Mich würde interessieren, wie stark Entwickler das nutzen und ob es Motivation gibt, bessere TUI-Monitoring-Tools zu bauen.
    Wenn ich auf einen Server gehe, starte ich als Erstes tmux und weise ein Fenster btop zu.

  • Für mich bedeutet Linux-Performance-„Tuning“ im Grunde das Deaktivieren der Spectre/Meltdown-Mitigationen.
    In diesem Fall laufen die Compute-Nodes in einer VPC ohne Internetzugang, daher wirkt das Risiko ziemlich gering.

    • Das hängt davon ab, welche CPU man verwendet. Bei Zen 4 wurde das Deaktivieren der Mitigationen nicht unterstützt und führte zu Bugs oder Crashes.
      Dieser konkrete Crash scheint behoben zu sein, aber ich würde es trotzdem nicht empfehlen. Moderne CPUs von AMD und Intel sind darauf ausgelegt, zumindest mit den grundlegenden Mitigationen aktiviert zu laufen.

  • Als Lesezeichen gespeichert. Wird mir vermutlich bald bei etwas nützen, an dem ich gerade arbeite
    Ich habe die Folien noch nicht komplett gelesen, frage mich aber, ob jemand schon einmal durch Kernel-Build-Optionen einen spürbaren Performance-Gewinn gesehen hat
    Früher, als ich Gentoo nutzte und an Build-Flags herumgeschraubt habe, habe ich das Kernel-Makefile geändert, um -O3 zu verwenden, und einen Patch für -march=native angewendet. Rückblickend scheint das laut Phoronix-Benchmarks bei mehreren Workloads eher schädlich zu sein; ich frage mich, ob jemand Gegenbeispiele gesehen hat

  • Gute Site. Sie neigt dazu, Linux-Performance zusammenzufassen, ob Tuning oder Monitoring, und lässt einen erst einmal tief Luft holen
    Das Thema ist tief, und es gibt sehr viele Arten von Beobachtungstools. Zumindest uptime, dmesg und iostat sollte man gut kennen. Diese Tools geben einen Überblick über verschiedene Systemaspekte wie Last, Speicher und CPU und liefern erste Hinweise für die Zustandsdiagnose. Das ist Seite 1 von 100 meiner „Schauen wir mal rein“-Checkliste
    In der Methodik der Performance-Analyse werden sorgfältige Benchmarks empfohlen, um das Systemverhalten und die Workload-Eigenschaften ganzheitlich zu bewerten. Man sollte Szenarien vor und nach Änderungen vergleichen, zunächst kleine Änderungen vornehmen und dann diejenigen, die einen Nutzen bringen, schrittweise zusammenführen. Labor und Produktionsumgebung verhalten sich niemals exakt gleich
    Ab hier wird es knifflig. CPU-Profiling mit Tools wie perf und Visualisierungen wie Flame Graphs ermöglichen eine gezielte Analyse der CPU-Aktivität; ergänzt um das Tracking von Hardware-Events lässt sich die Recheneffizienz weiter optimieren. Man muss mehr wissen als nur „Das ist ein App-Problem, vor dem letzten Release des Entwicklerteams war alles in Ordnung“
    Wenn man als Admin mit Entwicklern spricht, braucht man unter Linux Tools wie ftrace und BPF. Damit lassen sich die Ausführung von Kernel-Funktionen und Systemaufrufe detailliert nachverfolgen, was für Fehlerbehebung und Performance-Optimierung wichtig ist. Umgekehrt muss man als Entwickler möglicherweise die Intuition des Admins überprüfen. Wie man sagt: Vertrauen ist gut, Kontrolle ist besser
    Wenn es der eigene Code ist, sollte man BPF kennen. BPF ermöglicht nicht nur effizientes Tracing im Kernel, sondern unterstützt auch die Entwicklung fortgeschrittener, maßgeschneiderter Profiling-Tools mit bcc und bpftrace und erlaubt tiefere Einblicke in die System-Performance
    Abschließend: Das ist wirklich schwierig. Tuning bedeutet, zahlreiche Systemkomponenten und Kernel-Parameter anzupassen, von CPU und Speicher bis hin zu Netzwerkeinstellungen, um Performance und Zuverlässigkeit für unterschiedliche Workloads zu optimieren. Oder man schiebt es einfach auf das Netzwerk
    In der Praxis braucht man eine gute Haltung zum Change Management. Das Nachjagen von Code oder Kernel-Parametern kann alle überfordern, und unter Zeitdruck steigt durch den Druck die Wahrscheinlichkeit menschlicher Fehler