Anzeige PVE-Dashboard

T

TErxleben

Famous Member
Oct 20, 2008
813
207
113
Hamburg
Wie soll man denn die willenlose Anzeige im Dashboard (Durchschnittliche Auslastung, direkt unter CPU-Auslastung) interpretieren?
 
Last edited:
Last edited:
  • Like
Reactions: Johannes S and news
ThoSo said:
Würdest Du hier auch mal suchen (geht auch locker via Google) -> https://forum.proxmox.com/threads/understanding-cpu-usage-and-server-load.73692/

Dann hättest auch Fabian's Link gesehen ..... https://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html

Schaut unter Linux HTOP so aus:

View attachment 98459


Sommerloch? Langeweile? Gedankenspiele? :cool:
Click to expand...
Weder noch.
Ein satt 10J alter Beitrag von Brendan hilft da auch nichts. Hier geht es um Anzeigen in der PVE-GUI! Die findet hier mit keinerlei Einheit und ganz ohner Erklärung statt.
Sondern es sind nur hingerotze Zahlen, die man in keine Relation setzen kann.
Das schon die htop-Anzeige unterirdisch ist, muss nicht dazu führen, diese Werte unbewertet zu übernehmen.
Wie bewertest du denn einen htop-Wert von 1.21 auf einem Rechner, der Däumchen dreht?
 
Last edited:
TErxleben said:
Ein satt 10J alter Beitrag von Brendan hilft da auch nichts. Hier geht es um Anzeigen in der PVE-GUI! Die findet hier mit keinerlei Einheit und ganz ohner Erklärung statt.
Sondern es sind nur hingerotze Zahlen, die man in keine Relation setzen kann.
Das schon die htop-Anzeige unterirdisch ist, muss nicht dazu führen, diese Werte unbewertet zu übernehmen.
Click to expand...
Sag mal, das ist ja alles schön und gut, was dich da gerade so umtreibt.
Zum einen sind die Werte von HTOP mit Sicherheit die selben wie in der GUI (unterstelle ich jetzt einfach einmal).
Da stellt sich mir die Frage, warum ein 10 Jahre alter Artikel "überholt" sein soll - wir sind hier bei Linux und nicht bei dem M$ Windows System. Und Selbst dort hält sich das altgebackene taufrisch.

Wie bewertest du denn einen htop-Wert von 1.21 auf einem Rechner, der Däumchen dreht?
Click to expand...
Ich schau mir diese eigentlich nicht an - es ist schön das es die gibt. Und es mag durchaus seine Da-Sein Berechtigung haben. Gebraucht habe ich die noch nie, ich störe mich aber auch nicht an der Darstellung!

Ob das das jetzt "unterirdisch" oder "dahingerotzt" ist - ist deine persönliche Empfindung. Das hat weder Hand noch Fuß!
 
Last edited:
  • Like
Reactions: Johannes S
Generell ist die LOAD bei Linux eine etwas "silly metric" (so die Linuxkernelentwickler: https://github.com/torvalds/linux/blob/master/kernel/sched/loadavg.c ), da sie eben nicht nur CPU-Auslastung sondern auch andere Sachen wie IO berücksichtigt, zum Anderen aber eben einen Wert über die letzten 5/10/15 Minuten darstellt, der je nach sonstigen Systemparametern (eine Load von 5 bei 15 Prozessoren ist harmlos, bei 1 dagegen hoch bedenklich) mehr oder weniger hilfreich sein kann. Darum hat das Nagios-Plugin auch einen Switch, um den Wert durch Anzahl der CPUs zu teilen, um die Werte etwas sinnvoller zu kriegen. Auch das sagt ohne Kontext aber nur wenig aus: Wenn ich einmal am Tag (weil dann z.b. ab 23:00 Uhr ein fetter Job zum OCRen eines Haufens gescannter Dokumente läuft, die tagsüber reingekommen sind) die Werte hochgehen, muss das ja nicht weh tun. Tagsüber wenn z.B. Sachbearbeiter erwarten über den gleichen Server auf diese Scans zuzugreifen dagegen schon.

In neueren Linux-Kerneln gibt es darum ja die Load Pressure Metriken, die deutlich hilfreicher sind (und auch im PVE-Dashboard ablesbar), die sagen nämlich aus, wie lange Prozesse im Schnitt auf angeforderte Ressourcen (CPU, RAM, IO) warten mussten: https://www.linux-magazin.de/ausgaben/2020/08/psi/

Zur CPU Load und anderen silly metrics gab es bei der Fosdem2024 auch einen erfreulich kurzen (< 30 Minuten) Vortrag: https://archive.fosdem.org/2024/sch...1-linux-load-average-and-other-silly-metrics/

Und (ja ich bin Fanboy) Kristian Koehntopp hat im Laufe der Jahre auch einiges zur Load und wofür sie brauchbar ist und wofür nicht geschrieben:

https://blog.koehntopp.info/2005/06/24/wieviel-load-darf-es-denn-sein/
https://blog.koehntopp.info/2012/08/28/load-load-testing-und-benchmarks/
https://blog.koehntopp.info/2020/06/08/waffle-house-index-of-tooling/

Bei begrenzter Zeit reicht es den letzten Artikel zu lesen, bei sehr begrenzter Zeit dessen conclusio:

TL;DR​

  • If CPU load alerting worked, reactive autoscaling would work, too.
  • In a web workload environment, it usually doesn’t.
  • If you experiment, you need to attribute cost and benefit to experiment variants.
    • That means load tests with production users.
    • That means detailed, many-dimensional metrics with many tags, and a lot of ad-hoc metrics exploration.
  • Once you have that, you are also ready for predictive autoscaling, which actually works.
and

  • If your shop uses CPU load alerting, chances are that their tooling and education is in need of emergency updating.
Kristian Koehntopp https://blog.koehntopp.info/2020/06/08/waffle-house-index-of-tooling/
Click to expand...

Mit anderen Worten: Statt sich über zu hohe Last alamieren zu lassen, sollte man eher anhand der Produktion ermitteln bis zu welcher Last die Workloads noch vertretbare Reaktionszeiten liefern und sobald sie dies nicht mehr tun dann automatisiert z.B. der VM zusätzliche Ressourcen zuweisen oder neue VMs als Worker provisionieren. Darum ist es auch durchaus sinnvoll die Load zu überwachen, aber eben nicht für Alarme, die gehen dann nämlich entweder ständig los (wenn du gerade genug Ressourcen hast wie du brauchst und kaum weniger, also bei jeden Spike) oder zu spät ;) Problem: Das setzt sehr viel "Versuch und Irrtum" bei gleichzeitigen Messen in der Produktion (Testumgebungen sind einfach nie verlässlich) voraus, was wiederum eine eigene Wurmkanne/Kaninchenbau ist ;)
Ohne sinnvolles Monitoring (und nein das PVE Dashboard ist das nicht) kann man da kaum was machen.
 
  • Like
Reactions: TErxleben, ce3rd, UdoB and 1 other person
You must log in or register to reply here.
Top Bottom
Back