Top, Userprozesse und Systemprozesse
Hallo,
Ich habe mehrere Maschinen, welche alle
identische Hard- und Software und je einen
zeitkritischen Prozess haben.
Hier die Kopfzeile von "top" auf zwei dieser
Maschinen:
Maschine 1:
-----------
top - 11:16:45 up 9 min, 1 user, load average:\
0.88, 0.71, 0.38
Tasks: 58 total, 1 running, 57 sleeping, 0\
stopped, 0 zombie
%Cpu(s): 4.5 us, 27.3 sy, 0.0 ni, 68.0 id, 0.0\
wa, 0.0 hi, 0.2 si, 0.0 st
KiB Mem: 2074168 total, 151384 used, 1922784\
free, 0 buffers
KiB Swap: 0 total, 0 used, 0 free, 44352 cached
Maschine 2:
-----------
top - 11:16:57 up 19 min, 1 user, load average:\
0.74, 0.76, 0.55
Tasks: 56 total, 1 running, 55 sleeping, 0\
stopped, 0 zombie
%Cpu(s): 28.2 us, 3.5 sy, 0.0 ni, 68.2 id, 0.0\
wa, 0.0 hi, 0.2 si, 0.0 st
KiB Mem: 2074168 total, 150992 used, 1923176
free, 0 buffers
KiB Swap: 0 total, 0 used, 0 free, 44332 cached
Der zeitkritische Hauptprozess ist ziemlich
deterministisch und hält die Last fast
konstant. Er verwendet threads wobei nur einer
eine erhöhte Priorität hat und bei etwa 50%
plus/minus etwa 0.5% läuft. Jede Maschine hat
zwei Computer, alle mit Debian. Die fraglichen
haben eine alte Version (weil ich den kernel
nicht ändern kann), ca. 2013.
Was ich mir nicht erklären kann ist, warum bei
einem "us" niedrig und "sy" hoch, beim anderen
aber umgekehrt ist. Das hat zur Folge, daß die
Maschine mit hohem "us" die Gesamtlast (erste
Zeile) sehr langsam aber doch steigert, bis der
zeitkritische Thread scheinbar nicht mehr in
der Lage ist, seine Aufgaben in der geplanten
Zeit abzuarbeiten. Das dauert ein bis zwei
Tage. Die Maschine wird dann instabil und zeigt
150-200% Last (erste Zeile), welche aber mit
keiner anderen Zeile erklärt werden kann. Aber
selbst, wenn ich das eine Woche lasse, steigt
die Last nicht über dieses Maß. Da die CPU zwei
Kerne hat, sollte dies eigentlich noch nicht zu
Zeitproblemen führen (tut es aber).
Das sind industrielle Computer mit VME-Bus
(kernel 3.8.0, leider unveränderlich), sodaß
eine erhöhte Aktivität der Systemprozesse
durchaus nachvollziehbar ist. Sie haben keine
Festplatte und verwenden das rootfs via nfs.
Das läuft auf einem jeweils zweiten Computer,
welcher auch stets identische Hardware besitzt.
Ich habe versucht herauszufinden, wo denn da
ein Unterschied besteht. Die Konfiguration
(uboot) der VME-Computer wird über eine
serielle Verbindung gemacht, ist aber
identisch. Die Netzwerk-Konfiguration ist auch
identisch, wobei dieses interne Netzwerk vom
lokalen Netzwerk isoliert ist. (der zweite
Computer hat ein zweites Interface ohne
forwarding, wo dann verschiedene lokale
Adressen verwendet werden). Sogar die
Logdateien (kern.log, syslog, daemon.log)
unterscheiden sich nur im Zeitstempel. Valgrind
hat gezeigt, daß da kein memory-leak ist.
Tatsächlich hat dieses Setup nun einige Jahre
problemlos funktioniert, bis ich eine Änderung
an Netzwerkadresse und -Maske gemacht habe
(früher war das interne Netzwerk nicht
isoliert). Beide Fälle oben sind mit dieser
neueren Konfiguration.
Auf Maschinen, die tendieren hochzudrehen, habe
ich festgestellt, daß die Ausgabe von Logdaten
auf dem NFS-Dateisystem das Problem
verschlimmern (es geht aber nicht ganz weg, wenn
diese nicht geschrieben werden). Bei den
Maschinen, wo "sy" hoch und "us" niedrig ist,
kann ich Logdateien schreiben wo ich will, es
bleibt trotzdem stabil.
Gibt es eine Möglichkeit herauszufinden, welche
Prozesse diese "us" und "sy" tatsächlich
erzeugen, selbst wenn die eigentliche
Prozesstabelle dafür keine Ursache erkennen
läßt? Wie ist es möglich, daß zwei identische
Systeme (die software wird per disk image
kopiert, geändert werden nur Netzwerkadressen
und Maschinenparameter) so unterschiedlich
reagieren? Wenn ich mit "H" die threads einzeln
anzeige, sind alle threads im Bereich des
Üblichen. Auch der zeitkritische, selbst wenn
die Maschine schon instabil ist.
Da ich wirklich keine Ahnung habe, woran das
liegen kann, weiß ich auch nicht recht, welche
weiteren Informationen helfen könnten, die
Ursache zu finden. Wenn jemand eine Idee hat,
reiche ich das gerne nach.
Danke,
Reply to: