Hallo Liste, ich möchte/soll :P eine Aussage über die Auslastung eines Systems treffen. "top" wirft mir auf dem System eine floatingpoint exception, daher kommt es also monitoring-tool leider nicht in Frage. Wenn ich /proc/loadavg monitore, kriege ich nur in 10% der Fälle einen Wert != 0.00 für die letzte Minute (habs 24h laufen lassen). Das gleichzeitig gesichtete /proc/meminfo sagt, das ca. 450MB Speicher frei sind (2 GB insgesamt). Auf den Fast-Ethernet-Interfaces sind nach Aussage von ifconfig erst ein paar Gigabyte innerhalb der uptime von >400 Tagen gelaufen. Ergo würde ich sagen, dass die Kiste doch noch einiges an Leistung offen hat. Habe ich was vergessen/übersehen oder ist der Standpunkt so haltbar? Welche Dateien/Schnittstellen sollte man noch überwachen, um eine solche Aussage zu treffen? Grüße Dominik
Dominik Klein wrote:
Hallo Liste,
ich möchte/soll :P eine Aussage über die Auslastung eines Systems treffen.
"top" wirft mir auf dem System eine floatingpoint exception, daher kommt es also monitoring-tool leider nicht in Frage.
Uh, wenn ein Tool wie "top" eine exception meldet, würde mich das erst einmal nervös machen.
Wenn ich /proc/loadavg monitore, kriege ich nur in 10% der Fälle einen Wert != 0.00 für die letzte Minute (habs 24h laufen lassen). Das gleichzeitig gesichtete /proc/meminfo sagt, das ca. 450MB Speicher frei sind (2 GB insgesamt).
Gesamtüberblick mit buffers/cache wäre interessant. was meldet "free"?
Auf den Fast-Ethernet-Interfaces sind nach Aussage von ifconfig erst ein paar Gigabyte innerhalb der uptime von >400 Tagen gelaufen.
Darauf kannst du dich nicht verlassen, da der Zähler einen Überlauf hat und dann wieder bei Null anfängt.
Ergo würde ich sagen, dass die Kiste doch noch einiges an Leistung offen hat. Habe ich was vergessen/übersehen oder ist der Standpunkt so haltbar? Welche Dateien/Schnittstellen sollte man noch überwachen, um eine solche Aussage zu treffen?
Leistung bedeutet einmal, ob er genug Reserven für Anforderungsspitzen hat und wie das System im Durchschnitt belastet wird. Schau dir mal sar an. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Uh, wenn ein Tool wie "top" eine exception meldet, würde mich das erst einmal nervös machen.
Punkt für dich. Ich habe einen strace auf top laufen lassen. Abgesehen von einigen unbedeutenden (No such file ...) Fehlern ist mir nichts aufgefallen. Die letzten Meldungen lauten: fstat64(6, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 read(6, "cpu 15725509 1920495 36883818 3"..., 4096) = 863 write(1, "CPU0 states: 18.0% user, 81.0% s"..., 65) = 65 --- SIGFPE (Floating point exception) --- +++ killed by SIGFPE +++
Gesamtüberblick mit buffers/cache wäre interessant. was meldet "free"?
total used free shared buffers cached Mem: 2068872 1689296 379576 0 92264 1293312 -/+ buffers/cache: 303720 1765152 Swap: 1574360 13984 1560376
Leistung bedeutet einmal, ob er genug Reserven für Anforderungsspitzen hat und wie das System im Durchschnitt belastet wird. Schau dir mal sar an.
Werde ich tun. Danke für den Hinweis - noch ein mir bis dato unbekanntes tool.
Dominik Klein wrote:
Uh, wenn ein Tool wie "top" eine exception meldet, würde mich das erst einmal nervös machen.
Punkt für dich. Ich habe einen strace auf top laufen lassen. Abgesehen von einigen unbedeutenden (No such file ...) Fehlern ist mir nichts aufgefallen. Die letzten Meldungen lauten:
fstat64(6, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 read(6, "cpu 15725509 1920495 36883818 3"..., 4096) = 863 write(1, "CPU0 states: 18.0% user, 81.0% s"..., 65) = 65 --- SIGFPE (Floating point exception) --- +++ killed by SIGFPE +++
Sagt mir leider nicht allzuviel, von welcher Datei versucht er denn, diese Informationen auszulesen? Vielleicht ist diese ja schon mit "seltsamen" Werten gefüllt. Vielleicht ist es am einfachsten, herauszufinden, wann das letzte Mal top in einem Update betroffen war und daraus dann top noch einmal zu installieren.
Leistung bedeutet einmal, ob er genug Reserven für Anforderungsspitzen hat und wie das System im Durchschnitt belastet wird. Schau dir mal sar an.
Werde ich tun. Danke für den Hinweis - noch ein mir bis dato unbekanntes tool.
Ich glaube, ntop hat auch einige Leistungswerte, die kontinuierlich geprüft werden, aber genau habe ich es nicht mehr im Kopf. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Dominik Klein wrote:
"stat /usr/bin/top" zu Folge vor mehr als 3 Jahren. Aber okay, ich suche die CDs mal raus und installiere die Version neu.
Kein Erfolg - die Exception bleibt.
Übel, da ich die Interna von top nicht kenne, vermute ich, dass ein Update einer Systemlibrary irgendwann mal zu Inkompatibilitäten geführt hat. Ich habe nur noch eine 9.0 im Einsatz, heute abend werde ich mal ein strace darauf loslassen, um zu sehen, wie das im normalen Betrieb aussieht. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Sandy Drobic wrote:
Dominik Klein wrote:
[floating point exception bei top]
[Reinstallation des RPM-Paketes]
Kein Erfolg - die Exception bleibt.
Übel, da ich die Interna von top nicht kenne, vermute ich, dass ein Update einer Systemlibrary irgendwann mal zu Inkompatibilitäten geführt hat. Ich habe nur noch eine 9.0 im Einsatz, heute abend werde ich mal ein strace darauf loslassen, um zu sehen, wie das im normalen Betrieb aussieht.
Ich hatte das gleiche Phaenomen mit einer Version von RedHat8 auf einem Cluster, eine "floating point exception" beim Programm "top". Ich konnte keine eigentliche Ursache fuer das Versagen finden, manchmal lief es auch, manchmal kam es zu o.a. Fehlermeldung, und strace und andere Tools brachten keinen Aufschluss (meist lief top, wenn es mit strace gestartet wurde). Es half, eine neue Version von procps zu compilieren und zu installieren. Cheers, Th.
Am Dienstag, 29. November 2005 12.13 schrieb Sandy Drobic:
Dominik Klein wrote:
Uh, wenn ein Tool wie "top" eine exception meldet, würde mich das erst einmal nervös machen.
Punkt für dich. Ich habe einen strace auf top laufen lassen. Abgesehen von einigen unbedeutenden (No such file ...) Fehlern ist mir nichts aufgefallen. Die letzten Meldungen lauten:
fstat64(6, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 read(6, "cpu 15725509 1920495 36883818 3"..., 4096) = 863 write(1, "CPU0 states: 18.0% user, 81.0% s"..., 65) = 65 --- SIGFPE (Floating point exception) --- +++ killed by SIGFPE +++
Sagt mir leider nicht allzuviel, von welcher Datei versucht er denn, diese Informationen auszulesen? Vielleicht ist diese ja schon mit "seltsamen" Werten gefüllt. Nur so zur Info: top liest aus /proc/stat die Zeilen für die CPU. Bei einem Dual-Prozessor System mit SuSE 8.1 erhalte ich folgende Werte: cpu 5481367 40356 5431911 2268890866 cpu0 1421269 14955 1404519 567120382 cpu1 1329058 6613 1318027 567307427 cpu2 1419017 11115 1382513 567148480 cpu3 1312023 7673 1326852 567314577 Gut möglich, dass die Werte in /proc/stat merkwürdig sind, und dann beim Umrechnen einen Fehler produzieren. Z.B. Division durch 0 o.ä.
Es sieht bei mir zumindest auf den ersten Blick ähnlich aus: cpu 15732837 1920495 36889226 3925322134 cpu0 3948292 555769 8019339 4203668245 cpu1 3869428 377703 10308156 4201636358 cpu2 3912631 560705 8206726 4203511583 cpu3 4002486 426318 10355005 4201407836 Auch wenn ich nicht wirklich weis, was das bedeutet, so ist mir doch folgendes aufgefallen: Die Summe der Werte in der ersten Spalte von cpu0-3 ergeben die erste Spalte in der cpu-Zeile. Das gleich gilt für Spalte 2 und 3. In der vierten stimmt das aber nicht überein - im Gegensatz zu den Werten aus deinem Posting. Was bedeutet das nun?
Nur so zur Info: top liest aus /proc/stat die Zeilen für die CPU. Bei einem Dual-Prozessor System mit SuSE 8.1 erhalte ich folgende Werte: cpu 5481367 40356 5431911 2268890866 cpu0 1421269 14955 1404519 567120382 cpu1 1329058 6613 1318027 567307427 cpu2 1419017 11115 1382513 567148480 cpu3 1312023 7673 1326852 567314577 Gut möglich, dass die Werte in /proc/stat merkwürdig sind, und dann beim Umrechnen einen Fehler produzieren. Z.B. Division durch 0 o.ä.
participants (4)
-
Dominik Klein -
Sandy Drobic -
Thomas Hertweck -
Werner Merz