Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Wenn ich Dich richtig verstehe hast Du 0%-10% Last mit 30 Oszis auf echter HW? Das ist doch perfekt
Ja, mit meinem Baustein, mit Deinem sinds 120%
Also 120% von insgesamt 400%, also so 30-35%. Das fuehrt auf einigen Systemen schonmal dazu, dass die Kerne nicht in den Stromsparmodus gehen.
Trotzdem ist die CPU-Anzeige in der Admin-GUI falsch. Zumindest bei mir
Ich weiß - die Anzeige ist mit Vorsicht zu genießen (PHP-Funktion). Daher ja auch der etwas sperrige Umweg mit der Core-Anzahl in der edomi.ini usw. Klar könnte ich auch "top" parsen oder proc/sonstwas - aber bislang war ich mit der CPU-Anzeige recht zufrieden... (top zeigt bei mir in Etwa das gleiche an)
EDIT:
Dein LBS funktioniert ja auch gänzlich anders - ist ja quasi nur ein PHP-Script in einer Endlosschleife. Mein LBS ist bedingt durch die Logikengine tiefer verzahnt und greift im ms-Takt auf eine mySQL-Memory-DB zu... Bedenke aber, dass im EXEC-Abschnitt die [refresh]-Eigenschaft der Eingänge nicht genutzt werden können/dürfen! Da liegt nämlich schnell der Hase im Pfeffer
Ich hab mal ein sar eine Minute durchlaufen lassen, das Ergebnis ist:
Code:
Durchschn.: CPU %user %nice %system %iowait %steal %idle
Durchschn.: all 21,09 0,00 11,67 0,00 0,00 67,23
Also 30-35% Gesamtauslastung (auf 4 Kerne verteilt). Die admin-GUI zeigt mir einen konstanten Graphen bei 0%. Das ist nicht einfach nur ungenau, das ist irgendwie schlimmer
BTW: mit meinem LBS anstatt deinem (wieder jeweils 30, admin-GUI zeigt uebrigens noch immer 0% an):
Code:
Durchschn.: CPU %user %nice %system %iowait %steal %idle
Durchschn.: all 3,70 0,00 2,79 0,12 0,00 93,39
Nimmst du jetzt "Deine" Anzeige als Performance-Indikator siehst du natuerlich den Vorteil am der Daemon Variante nicht. Aber wenn man meine Performance-Werte als Grundlage heranzieht hat das schon ne Existenzberechtigung... finde ich zumindest...
Zuletzt geändert von wintermute; 19.02.2016, 21:59.
Grund: typo
Verstehe ich nicht... Bei mir zeigt EDOMI ziemlich exakt das gleiche wie "top" an. Ist ja nicht so, dass ich mich nicht ausgiebig damit beschäftigt hätte beim Implementieren Ich vermute mal, dass dies am Linux-Kernel bei Dir liegt?! Das Original CentOS 6.5 hast Du ja nicht mehr - oder?
EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)
Ich vermute mal, dass dies am Linux-Kernel bei Dir liegt?! Das Original CentOS 6.5 hast Du ja nicht mehr - oder?
Das mit dem Kernel war ja auch meine anfaengliche Vermutung, aber daran duerfte es nicht liegen:
Code:
[root@edomi ~]# cat /etc/redhat-release
CentOS release 6.7 (Final)
[root@edomi ~]# cat /proc/version
Linux version 2.6.32-573.18.1.el6.x86_64 (mockbuild@c6b8.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) ) #1 SMP Tue Feb 9 22:46:17 UTC 2016
Ich weiss jetzt nicht mehr, welches der Originale 6.5er Kernel war, aber laut meiner grub.conf isset der hier: 2.6.32-431.el6.x86_64
Ich kann gern damit nochmal booten und testen, ist ja keine Sache. Aber das erklaert ja auch nicht wieso Du mit 1024 Oszis 10% CPU Last hast und ich mit 30 Oszis 125%.
Ich kann auch - fuer Spass - nochmal ein 6.5er aufsetzen und alles auf Anfang drehen, aber das wird am Verhalten vermutlich nix aendern.
Welche php-Klasse ermittelt die Werte denn? Irgendein Standard-Vorgehen wie man das mit php machen sollte ist mir nicht bekannt, ich kenn das nur mit "eigenem" Auswerten von irgendwelchen /proc Pseudo-Files... wenn das in Edomi auch so laeuft, dann kann es nur am Kernel liegen - was aber eigentlich bei nem "Upgrade" von 2.6.32 auf 2.6.32 auch nicht passieren darf, es sei denn, die RHEL Leute haben da groben Murks verbaut.
Du darfst natürlich gerne recherchieren - die PHP-Funktion zur Ermittlung der Last ist sys_getloadavg() - implementiert ist dies so:
PHP-Code:
function getCpuLoadInfo() { //CPU-Last in Prozent //return: 0..100 [INT]: CPU-Last in Prozent if ($n=sys_getloadavg()) { return intVal($n[0]*100/global_CPUs); } else { return 0; } }
EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)
Du darfst natürlich gerne recherchieren - die PHP-Funktion zur Ermittlung der Last ist sys_getloadavg() - implementiert ist dies so:
Da haben wirs
Die Load (was sys_getloadavg) zeigt nicht die CPU Auslastung, sondern die durchschnittliche Anzahl an wartenden Prozessen im System, was mit der CPU *Auslastung* erstmal nix zu tun hat ( warten auf I/O kann zB die Load erhoehen ohne die CPU Auslastung signifikant zu erhoehen).
Natuergemaess ist das dann auch kein Prozentwert, sondern ein absoluter Wert - was zu Verwirrungen und Verwechselungen mit der CPU Auslastung fuehren kann. Die beiden Werte haengen zwar prinzipbedingt meistens zusammen, jedoch kann man keinen analytischen (oder numerischen) Zusammenhang zwischen beiden feststellen.
Da die Load ein absoluter Wert ist, muss man die auch nicht mit 100 multiplizieren und danndurch die Cores teilen, die Load ist naemlich (wie gesagt) ein Absolutwert und nicht von den CPUs "an sich" abhaengig.
Kurz gesagt: die errechneten Werte haben keine wirkliche Aussagekraft, muessten aber (wenn man das *100/Cores wieder rausrechnet) exakt dem enstprechen, was ein top ganz weit oben bei "load average" anzeigt.
Um Verwirrungen zu vermeiden nennt man das eine gern "CPU usage" und das andere "System load", wobei Systemlast - wie gesagt - nichts mit den Cores zu tun hat (wenn 100 Prozesse auf Platten-IO warten ist die Anzahl an Cores zB egal wenn ich nur eine Platte habe), CPU Usage aber auch nix damit zu tun hat (oder haben muss), wie viele Prozesse in der Queue warten.
Dass die Load steigt wenn zB Edomi gestartet wird ist daher klar und auch nicht ungewoehnlich. Wenn der Wert dauerhaft in die Naehe von 1 kommt, sollte man nachsehen wieso: ist das Problem rein rechenzeitbedingt (also viel CPU states), dann fallen die Cores ins Gewicht (und man kann sagen die Load kann ruhig in die Naehe der Core-Anzahl rutschen ohne das es ungemueltich wird). Ist das Problem aber zB I/O bedingt, dann helfen Cores auch nicht wirklich weiter. Oder auch: wenn Edomi dauerhaft eine signifikante Load erzeugen sollte, dann kann man mit spuerbaren Verzoegerungen in der Abarbeitung rechnen.
Die CPU Usage hingegen ist was anderes - und darum gings mir (das ist der Prozent-Wert der beim top angezeigt wird). Die steigt naemlich signfikant an wenn man Rechenarbeit durchfuehrt und kann dann auch verhindern, dass Kerne in den Stromsparmodus schalten.
Kurzum: wenn du nur einen Prozess hast der PI berechnet, dann haste eine niedrige Load aber eine hohe CPU Usage. Hast du viele Prozesse im uninterruptable slep, dann hast du wenig CPU usage aber hohe Load.
Ich finde daher, Du solltest die amdin-GUI anpassen um Verwirrungen zu vermeiden (also statt "CPU %" vielleicht einfach "LOAD" reinschreiben und die *100/core Sache rausnehmen). Und ich persoenlich wuerde noch einen zusaetzlichen Graphen mit "CPU usage" (oder eben "CPU %") dazupacken.
Abschliessend: dass die Load bei 1024 (oder beliebig vielen) Oszis nicht steigt ist normal, es werden ja nicht mehr Prozesse. Die CPU Usage steigt trotzdem und da war die Verbesserung von meinem LBS zu sehen (der wiederum im Gegenzug die Load erhoeht, aber nicht spuerbar).
Durchaus richtig - und mir auch durchaus bekannt Danke dennoch für Deine umfangreichen Ausführungen!
In der Praxis ist dies allerdings nicht so bedeutend - denn letztlich spiegelt der %-Wert die CPU-Auslastung wieder. Glaub's mir
Ausserdem stimmt Deine Annahme nicht wirklich: Wenn Du das Ergebnis von sys_getloadavg() in Prozent umrechnest (in Abhängigkeit von der Core-Anzahl natürlich), entspricht dies (in Etwa) der CPU-Last. Das ist Fakt - auch wenn Du dies vielleicht nicht so siehst
Kannst Du ganz einfach testen:
Starte folgendes PHP-Script und staune:
PHP-Code:
while (true) {}
Ergebnis: CPU qualmt Und die CPU-Last steigt "stark" an... Was hat dies mit wartenden Prozessen zu tun? (klar, die ANDEREN Prozesse warten auf DIESEN Prozess... Nur bedeutet das im Umkehrschluss: Es steht 0% für andere Prozesse zu verfügung - oder anders ausgedrückt: DIESER Prozess verschlingt 100% der Ressourcen)
Ausserdem: Ich bin seit vielen Jahren mit EDOMI vertraut (ach nee) und habe schon so manches Experiment durch. Die CPU-Last-Anzeige passt wunderbar - daher bleibt diese auch wie sie ist! Niemanden (aus User-Sicht) interessiert die Technik dahinter, sondern nur die Bedeutung in der Praxis. Und die ist ganz klar: 100% bedeutet: Ende im Gelände 0% bedeutet: Alles gut.
EDIT:
Nur zum Verständnis: Natürlich entspricht der Wert nicht exakt der "CPU-Last" - schon klar. Aber der Effekt ist der gleiche... Und darum geht's in der Anzeige ja: "Wieviel "Rechenleistung" ist aktuell verfügbar?"
Ausserdem: Ich bin seit vielen Jahren mit EDOMI vertraut (ach nee) und habe schon so manches Experiment durch. Die CPU-Last-Anzeige passt wunderbar - daher bleibt diese auch wie sie ist! Niemanden (aus User-Sicht) interessiert die Technik dahinter, sondern nur die Bedeutung in der Praxis. Und die ist ganz klar: 100% bedeutet: Ende im Gelände 0% bedeutet: Alles gut.
EDIT:
Nur zum Verständnis: Natürlich entspricht der Wert nicht exakt der "CPU-Last" - schon klar. Aber der Effekt ist der gleiche... Und darum geht's in der Anzeige ja: "Wieviel "Rechenleistung" ist aktuell verfügbar?"
Da müsste "Top" und SAR extrem lügen.
Ich hatte das heute Nacht paar mal probiert und laufen lassen.
Selbst wenn deine Anzeige aus 5 oder 1 Minute mittelt, ist das NICHT reel.
Bsp.: Edomi startet und zeigt gern mal die 20% an, lasse ich sar oder top aber mitlaufen.
So sagt mir diese das die CPU niemals nie solche werte zu diesen Zeiten hat.
Die maximale Auslastung betrug 8%
Und ja ich habe 2 Cores angegeben.
Sofern muss ich Wintermute recht geben.
Versteh es bitte nicht falsch, es soll in keinster weiße deine Arbeit schlecht machen.
Scheinbar scheinen die anderen komischerweiße keine Abweichungen zu haben.
Was habt Ihr bloß für Probleme damit??? Nirgends steht "CPU-Last" - sondern nur "CPU". Dies soll ein Synonym sein für "Verbrauchte Ressourcen", nichts weiter. Die PHP-Funktion sys_getloadavg() liefert die mittlere "Load" zurück - NICHT die "CPU-Last". Darum geht es ja auch nicht... Wie soll ich den Wert denn sonst betiteln?! "CPU" versteht doch jeder sofort!
Wenn Ihr unbedingt die genaue CPU-Last(!) erfahren wollt, dann nutzt doch einfach top & Co. - dafür ist es ja gemacht. Aber es hat doch keinen Sinn die aktuelle(!) CPU-Last in EDOMI anzuzeigen - wen interessiert dieser Wert?!
Beispiel: Tankanzeige im Auto. Will ich wirklich wissen wieviele Liter Sprit ich noch habe? Oder wäre es nicht viel sinnvoller zu wissen, wie weit ich noch fahren kann...? Na also...
EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)
Wenn ich mich auf das Verlasse was angezeigt wird, dann hätte ich schon Angst das mein System mal bei Situation X anfängt extrem langsam zu werden.
Wenn da CPU steht gehe ich, nur rein für mich, davon aus, das damit auch die relativ aktuelle CPU Last ist, da kann sich jeder hineininterpretieren was er möchte.
Es ist nur unter anderen Vorraussetzungen immer anders und kann schon mal nix gescheides anzeigen.
Ich bin zu wenig mit Programmieren vertraut, aber auch Wintermutes Sachen klingen plausibel.
Wenn jetzt über 5 Minuten gemittelt 53% ausgelastet sind (und du vertraust deiner Anzeige), muss es ja einen Grund geben.
Ich denke Edomi wird nicht mit 4 banalen, total einfachen Visu's und 250 LBS (mitgelieferte nix importiertes) so angestrengt sein.
Der letzte Start eines Projektes ist inzwischen auch deutlich länger als 10Minuten her.
Scheinbar juckt es die anderen nicht oder die haben das Problem nicht.
Wenn du sagst es ist so Gesetz, das da durchaus komische Werte stehen dürfen dann ist das ebend so.
Aber vielleicht kann man ja auch mal auf Kritik eingehen und nicht mit dem Kopf durch die Wand und sagen das kann alles nicht sein.
Meinetwegen kannst du gern per TeamViewer dir es selber anschauen
Es hat mich verwirrt... und zwar nicht, weil da "CPU" steht, sondern weil da "CPU x%" steht (also Prozent) - das sieht halt mehr nach CPU usage als nach System Load aus. Denn es macht keinen Sinn, die Load in % anzugeben... das ist wie "dieser Salatkopf ist 18% schwer", oder "dieses Loch ist mindestens 300 Liter tief"
Zudem hat Load nix, aber auch garnix mit irgendeiner CPU zu tun - der Wert zeigt an, wieviele Prozesse warten, nix anderes.
Dass der Wert dann noch mit der kosmologischen - Entschuldigung: mit der Gaertner-Konstante multipliziert wird, macht es im Endeffekt nicht besser
Hab ich zB 2 Cores und eine tatsaechliche Load von 18, dann ergibt Deine Rechung doch 18*100/2=900%... was soll der Wert mir denn dann sagen? Ok... 9 fache Ueberlastung des Systems... koennte man reininterpretieren... ist aber falsch, denn es ist eine 18fache Ueberlastung. Die Cores da einzubeziehen ist "sinnfrei" (s.o.)
Ich faende es sinnvoller, da die tatsaechliche Load anzugeben (und dann auch Load dranzuschreiben) als irgendwelche umgeschwurbelten Werte, das verwirrt doch alle bloss. Wie diese Diskussion im uebrigen ganz wundervoll demonstriert
Und wenn man ein Balkendiagramm malt (wie in der GUI ebenfalls), was passiert denn da wenn der Wert über 100% steigt? Load hat halt keinen Hoechstwert (mein bisheriges Maximum war irgendwas um 280) - CPU Usage aber eben schon. Also wenn da % steht oder ein (legendenloses) Balkendiagramm angezeigt wird, dann geht man da (also ich zumindest) mit einer gewissen Erwartungshaltung ran.
Beispiel: Tankanzeige im Auto. Will ich wirklich wissen wieviele Liter Sprit ich noch habe? Oder wäre es nicht viel sinnvoller zu wissen, wie weit ich noch fahren kann...? Na also...
Zeigt mein Auto mir beides an. Das sagt mir sogar, wieviel Sprit aktuell pro 100km (oder Stunde, je nachdem) verbraucht wird.
Back to Topic: laut sar/top/proc/stat erzeugt ein (!) Oszi von Dir 6% CPU *Usage* und mein Daemon keine.. ätsch
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar