Performances Linux

 (brendangregg.com)
3 points par GN⁺ 2023-10-15 | 1 commentaires | Partager sur WhatsApp
  • La page Linux Performance de Brendan Gregg est un hub de liens qui réunit au même endroit les ressources d’observabilité, d’analyse, de benchmarking et de tuning nécessaires pour démarrer une investigation sur les performances Linux
  • Le parcours d’outils central passe par perf, eBPF, bcc, bpftrace et Flame Graphs, avec un accès direct aux exemples de commandes, aux outils de tracing et à la visualisation
  • La documentation s’étend à l’article de Netflix de 2015 sur l’analyse des performances, au tuning d’EC2, aux Linux load averages, aux frame pointers, aux exemples gdb et à deux livres sur les performances
  • La liste des conférences propose des parcours d’apprentissage selon le contexte, comme une vue d’ensemble en 40 minutes, un tutoriel outils en 90 minutes, l’analyse des performances des conteneurs ou une checklist SRE
  • Pour chaque carte d’outils, il faut vérifier sa fraîcheur via l’année indiquée en bas à droite de l’image, et le diagramme intégré n’est pas aussi complet que les autres diagrammes individuels

Hub de ressources sur les performances et cartes d’outils

  • Cette page est un hub de liens qui rassemble les ressources Linux performance créées par Brendan Gregg
  • L’image de la carte d’outils à droite a été conçue avec une grande police pour s’adapter aux présentations, et dans un format qui peut aussi être imprimé et affiché sur un mur de bureau
  • Les cartes d’outils présentent le travail sur les performances Linux en le répartissant dans les domaines suivants
  • Pour savoir à quel point chaque image est à jour, il faut vérifier l’année en bas à droite
  • Un diagramme haute résolution combinant l’observabilité, le tuning statique des performances et perf-tools/bcc est également fourni séparément
    • png
    • svg
    • Ce diagramme intégré n’est pas aussi complet que les autres diagrammes individuels

Principaux outils directement accessibles

  • perf : perf one-liners, exemples et ressources de visualisation
  • eBPF tools : outils de tracing BPF/bcc et exemples
  • perf-tools : ensemble d’outils perf basés sur Ftrace
  • bcc : ensemble d’outils de performance BPF/bcc
  • bpftrace : ensemble d’outils de performance BPF/bpftrace
  • Flame Graphs : guide d’utilisation des Flame Graphs avec perf et d’autres profileurs

Documentation et ressources d’apprentissage

Articles approfondis sur eBPF, ftrace et perf

Conférences recommandées selon le contexte

  • Linux Systems Performance, USENIX LISA 2019

    • Résume en 40 minutes les performances des systèmes Linux selon six angles : observabilité, méthodologie, benchmarking, profiling, tracing et tuning
    • video, youtube, slides, PDF

  • Linux Performance 2018, PerconaLive 2018

    • Résume en keynote de 20 minutes les évolutions et fonctionnalités récentes de Linux performance en 2018
    • youtube, slideshare, PDF

  • Linux Performance Tools, Velocity 2015

    • Tutoriel de 90 minutes couvrant l’observabilité des performances, le benchmarking, le tuning, le tuning statique des performances, les outils et méthodologies de tracing, ainsi que des démonstrations en direct
    • youtube playlist, slideshare, PDF

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

    • Met l’accent sur le tuning plutôt que sur l’observabilité des performances, et couvre le contexte de Netflix, les types et fonctionnalités d’instances AWS EC2, les paramètres ajustables du noyau Linux et l’observabilité
    • youtube, slideshare

  • Container Performance Analysis, DockerCon 2017

    • Explique comment localiser un goulot d’étranglement entre l’hôte et les conteneurs, profiler des applications conteneurisées et descendre plus profondément dans le noyau
    • youtube, slideshare

  • Broken Linux Performance Tools, SCaLE14x 2016

    • Couvre les problèmes fréquents dans les outils système Linux, les métriques, les statistiques, les visualisations, la surcharge de mesure et les benchmarks, avec des conseils « What You Can Do »
    • youtube, slideshare, PDF

  • Using Linux perf at Netflix, Kernel Recipes 2017

    • Se concentre sur le profiling CPU et le fonctionnement des Flame Graphs, en incluant les propriétés de perf_events et les problèmes de stack traces et de symbols lors du profiling de Java, Node.js, de VM et de conteneurs
    • 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

    • Couvre l’utilisation de l’enhanced BPF, ou eBPF, ajouté à la série Linux 4.x pour l’analyse de performances, l’observabilité et le débogage
    • Le front-end est le projet open source bcc, qui fournit des interfaces et un ensemble d’outils BPF
    • youtube, slideshare, PDF

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

    • Couvre les outils ftrace et perf_events, ainsi que perf-tools, qui utilise principalement ftrace
    • Présente ftrace comme un traceur intégré au noyau Linux depuis de nombreuses années, mais resté largement méconnu
    • youtube, slideshare, PDF

  • Performance Checklists for SREs, SREcon 2016

    • Inclut dans la seconde partie une checklist pour la réponse aux incidents de performance Linux, qui peut aussi être utile pour une analyse urgente des performances Linux
    • youtube, usenix, slideshare, PDF

Ressources externes recommandées

À lire aussi

1 commentaires

 
GN⁺ 2023-10-15
Avis de Hacker News

  • J’utilise tuned sur un VPS Debian/Ubuntu qui fait tourner une application temps réel, et ça fonctionne plutôt bien
    C’est plus simple que de modifier directement les paramètres du noyau, c’est-à-dire les réglages sysctl ou les tunables du noyau
    https://access.redhat.com/documentation/en-us/red_hat_enterp...
    sudo apt install tuned

    • On utilise aussi Tuned pour des charges de travail SAP, et on en est très contents

  • Je ne savais pas que Brendan Gregg était désormais chez Intel
    https://en.wikipedia.org/wiki/Brendan_Gregg
    C’est aussi le protagoniste de la vidéo virale Shouting in the Data Center
    https://www.youtube.com/watch?v=tDacjrSCeq4
    Un vrai génie

  • Il vaut la peine de souligner que presque tout ce que couvre l’article original concerne non pas la latence, mais le débit/la bande passante du réseau, du disque, des autres entrées/sorties et du CPU
    Pour beaucoup de gens, la performance signifie le débit, donc ça se comprend. Mais il y a aussi des cas où la latence est bien plus importante que le débit, et pour optimiser la latence sous Linux, il faut un autre ensemble d’outils

    • Remarque assez pertinente. Réduire la latence est aussi bien plus difficile que d’augmenter le débit[1], si bien qu’il est souvent important de s’en préoccuper
      Un autre axe que les gens peuvent optimiser est la performance par watt, mais je ne vais pas m’étendre là-dessus ici
      Il arrive aussi que l’optimisation du débit soit en même temps une optimisation de la latence. Par exemple, si l’on peut placer davantage de processus sur une même machine, la distance moyenne entre les processus et leurs interlocuteurs diminue, et la latence moyenne aussi
      Une évidence quand on optimise la latence est d’augmenter suffisamment le débit pour qu’il ne soit pas le goulot d’étranglement
      Quand on optimise agressivement la latence, j’ai l’impression qu’il n’y a pas tant de tuning Linux que ça. Je peux me tromper, mais il semble que l’essentiel concerne l’affinité des cœurs, l’exécution tickless, le réseau en espace utilisateur, ainsi que les réglages côté matériel comme la taille des pages, le SMT, l’économie d’énergie et le choix du matériel
      [1] https://pdfs.semanticscholar.org/bce7/5f78d340cac32dccd8631f...
    • Il me semble plus juste de parler de throughput plutôt que de bandwidth. Le sens est proche, mais l’opposition entre débit et latence est discutée depuis longtemps
      Parfois on peut améliorer les deux, mais en général c’est un compromis
    • Je serais curieux de connaître des outils ou ressources recommandables pour le tuning de la latence
    • Si l’objectif est de réduire la latence pour obtenir des caractéristiques temps réel du système, il est peu probable qu’une distribution Linux standard devienne satisfaisante, même en manipulant de nombreux réglages

  • Attendre est aussi une bonne stratégie
    Depuis Linux 6.5, le scheduler comprend que, lorsqu’un “cœur” SMT est occupé, placer quelque chose sur un autre “cœur” n’est pas forcément optimal. En pratique, cela ressemble davantage à un seul cœur avec un coût de changement de contexte très faible
    Grâce à cela, les tâches très parallèles sont devenues sensiblement plus réactives, et cela se voit aussi sur les graphiques d’utilisation CPU
    Les résultats peuvent varier à cause de la cohérence de cache et des problèmes NUMA

    • Sur les anciens noyaux aussi, la simple désactivation du SMT peut donner un effet plus réactif, bloquer certaines attaques par canal auxiliaire et améliorer l’efficacité énergétique

  • Articles liés :
    Linux Performance - https://news.ycombinator.com/item?id=13498485 - janvier 2017, 64 commentaires
    Linux Performance - https://news.ycombinator.com/item?id=8205057 - août 2014, 22 commentaires

  • Si quelqu’un veut modifier un paramètre tunable sans pouvoir expliquer pourquoi ce changement produirait l’effet souhaité, ni pourquoi il est réglé à cette valeur au départ, je ne le laisserais pas le faire en production
    On pourrait appeler ça le “paramètre tunable de Chesterton”

    • Même si l’on peut donner une raison hypothétique, il suffit de faire des benchmarks hors production, non ?

  • Quand on pense au travail de Brendan sur eBPF, ce document se lit comme une façon de surveiller et d’évaluer plus facilement diverses situations de performance
    Les ajustements et le tuning impliquent des compromis, et en général optimiser une chose se fait souvent au détriment d’une autre
    À côté de ça, btop m’a été très utile comme visualiseur TUI tout-en-un des performances et de la charge système, en remplacement de glances. Je me demande à quel point les développeurs l’utilisent, et s’il existe une motivation pour créer de meilleurs outils de monitoring en TUI
    Quand je me connecte à un serveur, la première chose que je fais est de lancer tmux et d’affecter une fenêtre à btop

  • Pour moi, le “tuning” des performances Linux revient à désactiver les mesures d’atténuation Spectre/Meltdown
    Dans ce cas, les nœuds de calcul tournent dans un VPC sans accès à Internet, donc le risque semble assez faible

    • Ça dépend du CPU utilisé. Sur Zen 4, la désactivation des atténuations n’était pas prise en charge et provoquait des bugs ou des crashes
      Il semble que ce crash précis ait été corrigé, mais je ne le recommanderais toujours pas. Les CPU récents d’AMD et d’Intel sont conçus pour fonctionner au moins avec les atténuations de base activées

  • Mis en favori. Ça devrait bientôt être utile pour ce sur quoi je travaille
    Je n’ai pas encore lu toutes les diapositives, mais je me demande si certains ont déjà constaté des gains de performance significatifs grâce aux options de build du noyau
    À l’époque où j’utilisais Gentoo et que je bricolais les flags de build, je modifiais le Makefile du noyau pour utiliser -O3 et j’appliquais un patch -march=native. Avec le recul, d’après les benchmarks Phoronix, cela semble plutôt nuisible sur plusieurs workloads ; je me demande si quelqu’un a déjà vu des contre-exemples

  • C’est un bon site. Il a tendance à vouloir résumer les performances Linux, que ce soit pour le tuning ou la supervision, ce qui fait prendre une grande inspiration
    Le sujet est profond, et les outils d’observation sont très nombreux. Il faut au minimum connaître en profondeur uptime, dmesg et iostat. Ces outils permettent de parcourir plusieurs aspects du système — charge, mémoire, CPU, etc. — et donnent les premiers indices pour diagnostiquer son état. C’est la page 1 sur 100 de ma checklist « jetons-y un œil »
    En matière de méthodologie d’analyse des performances, on recommande des benchmarks soigneux afin d’évaluer globalement le comportement du système et les caractéristiques du workload. Il faut comparer les scénarios avant/après, commencer par de petits changements, puis fusionner progressivement ceux qui semblent apporter un bénéfice. Un environnement de labo et un environnement de production ne se comportent jamais exactement de la même manière
    C’est à partir de là que ça devient délicat. Le profilage CPU avec des outils comme perf et des visualisations comme les flame graphs permet une analyse ciblée de l’activité CPU, et l’ajout du suivi des événements matériels permet d’optimiser l’efficacité du calcul. Il faut aller au-delà du « c’est un problème applicatif, tout allait bien avant la dernière release de l’équipe de dev »
    En tant qu’administrateur, quand on discute avec des développeurs, on finit par avoir besoin d’outils comme ftrace et BPF sous Linux. Ils permettent de tracer en détail l’exécution des fonctions du noyau et les appels système, ce qui est important pour résoudre les problèmes et optimiser les performances. À l’inverse, si l’on est développeur, il peut falloir vérifier l’intuition de l’administrateur. Comme on dit : faire confiance, mais vérifier
    Si c’est votre propre code, il faut connaître BPF. BPF permet non seulement un traçage efficace à l’intérieur du noyau, mais favorise aussi le développement d’outils de profilage avancés et personnalisés via bcc et bpftrace, donnant une vision plus profonde des performances du système
    Enfin, c’est vraiment difficile. Le tuning consiste à ajuster de nombreux composants système et paramètres du noyau, du CPU et de la mémoire jusqu’à la configuration réseau, afin d’optimiser les performances et la fiabilité pour divers workloads. Sinon, on peut toujours accuser le réseau
    En pratique, il faut surtout une bonne approche de la gestion des changements. Courir après le code ou les paramètres du noyau peut submerger tout le monde, et lorsque le temps presse, la pression augmente encore le risque d’erreur humaine