Top, Userprozesse und Systemprozesse

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Top, Userprozesse und Systemprozesse

ternaryd
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 | Threaded
Open this post in threaded view
|

Re: Top, Userprozesse und Systemprozesse

Rolf Reintjes
Am 28.05.2019 um 12:02 schrieb ternaryd:
> 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.

Die einzige Idee, die mir dazu eingefallen ist: mal htop anstatt top
verwenden und damit rumspielen.

Bist du in der Sache denn schon irgendwie weiter gekommen?

Gruss

Rolf



Reply | Threaded
Open this post in threaded view
|

Re: Top, Userprozesse und Systemprozesse

ternaryd
On Wed, 5 Jun 2019 23:28:43 +0200
Rolf Reintjes <[hidden email]> wrote:

> Die einzige Idee, die mir dazu eingefallen
> ist: mal htop anstatt top verwenden und
> damit rumspielen.

Ich kannte htop nicht, die manpage gibt mir
aber keinen Hinweis, wie ich dies für Kernel
Prozesse verwenden könnte.

> Bist du in der Sache denn schon irgendwie
> weiter gekommen?

Nicht wirklich.

Ein alter Kommentar im Netz sagt, der kernel
3.8.0 hätte einen bug/flaw, und daß das Problem
weg geht, wenn man unter /proc/sys/vm/ das
dirty_ratio auf 90, das dirty_background_ratio
auf 5 setzt. Mit so einer Einstellung kommen
sie seltener, bleiben aber länger und helfen am
Ende nichts.

Da das Problem sich abschwächen läßt, wenn ich
Schreibzugriffe unterbinde, gehe ich davon aus,
daß da ein Zusammenhang besteht. Verstehe bloß
nicht welcher.

NFS ist auf einer Seite v3, auf der anderen
v4, und ein NFS directory wird auf /home/
gemountet, wobei / ja schon NFS ist. Das hat
aber vorher immer funktioniert.

Bislang dachte ich auch, daß es relevant sei,
ob die unerklärte Zusatzlast bei "sy" oder bei
"us" auftaucht, ist aber egal. Nur wenn Ärger im
Anmarsch ist, dann ist bei beiden so 20-30, der
loadavg geht dann auf 1.8 oder 1.9 und von da
bis zum reboot nie wieder runter (Aber auch
nicht rauf).

Die Architektur ist powerpc, der kernel ist
nicht "tainted", hat aber einen real time
patch.

Ich bin mir fast sicher, daß ich beim Vergleich
des funktionierenden Systems mit den anderen
irgendwo irgendwas übersehen habe, aber nach
Wochen des Suchens bin ich immer noch clueless™.

Die Anzahl der Antworten hier sagt mir, daß das
vielleicht doch kein 0-8-15 Problem ist.

Reply | Threaded
Open this post in threaded view
|

Re: Top, Userprozesse und Systemprozesse

Stefan Krueger
Nunja, ich hätte da viele fragen..

Warum nimmst du nicht einen Kernel aus den Backports? Und warum ein RealTime-Patch ich hab bis jetzt immer nur gelesen(!) das es mehr Probleme als Lösungen schafft.
Und NFSv3 auf der einen und NFSv4 auf der anderen Seite, was meinst du damit genau? Wenn der Server v3 rausreicht dann kann der Client nicht v4 mounten, oder verstehe ich da was falsch?

Um zu sehen was der Kernel und damit das System macht, brauchst du perf, das Kommando wäre dann 'perf top' das zeigt die an welche Calls gemacht werden und und mit etwas Hilfe von deiner Suchmaschine weisst du auch was dieser Call genau macht und kannst so überlegen wo/ob da der Falschenhals ist bzw was dort die Last verursacht




On Thursday, June 6, 2019 1:33:55 AM CEST ternaryd wrote:

> On Wed, 5 Jun 2019 23:28:43 +0200
> Rolf Reintjes <[hidden email]> wrote:
>
> > Die einzige Idee, die mir dazu eingefallen
> > ist: mal htop anstatt top verwenden und
> > damit rumspielen.
>
> Ich kannte htop nicht, die manpage gibt mir
> aber keinen Hinweis, wie ich dies für Kernel
> Prozesse verwenden könnte.
>
> > Bist du in der Sache denn schon irgendwie
> > weiter gekommen?
>
> Nicht wirklich.
>
> Ein alter Kommentar im Netz sagt, der kernel
> 3.8.0 hätte einen bug/flaw, und daß das Problem
> weg geht, wenn man unter /proc/sys/vm/ das
> dirty_ratio auf 90, das dirty_background_ratio
> auf 5 setzt. Mit so einer Einstellung kommen
> sie seltener, bleiben aber länger und helfen am
> Ende nichts.
>
> Da das Problem sich abschwächen läßt, wenn ich
> Schreibzugriffe unterbinde, gehe ich davon aus,
> daß da ein Zusammenhang besteht. Verstehe bloß
> nicht welcher.
>
> NFS ist auf einer Seite v3, auf der anderen
> v4, und ein NFS directory wird auf /home/
> gemountet, wobei / ja schon NFS ist. Das hat
> aber vorher immer funktioniert.
>
> Bislang dachte ich auch, daß es relevant sei,
> ob die unerklärte Zusatzlast bei "sy" oder bei
> "us" auftaucht, ist aber egal. Nur wenn Ärger im
> Anmarsch ist, dann ist bei beiden so 20-30, der
> loadavg geht dann auf 1.8 oder 1.9 und von da
> bis zum reboot nie wieder runter (Aber auch
> nicht rauf).
>
> Die Architektur ist powerpc, der kernel ist
> nicht "tainted", hat aber einen real time
> patch.
>
> Ich bin mir fast sicher, daß ich beim Vergleich
> des funktionierenden Systems mit den anderen
> irgendwo irgendwas übersehen habe, aber nach
> Wochen des Suchens bin ich immer noch clueless™.
>
> Die Anzahl der Antworten hier sagt mir, daß das
> vielleicht doch kein 0-8-15 Problem ist.
>



Reply | Threaded
Open this post in threaded view
|

Re: Top, Userprozesse und Systemprozesse

ternaryd
On Thu, 06 Jun 2019 10:40:31 +0200
Stefan K <[hidden email]> wrote:

> Nunja, ich hätte da viele fragen..

Werde versuchen sie alle zu beantworten.

> Warum nimmst du nicht einen Kernel aus den
> Backports?

Ein Backport setzt einen stock-kernel voraus.
Diesen hab ich aber selbst gebaut. Für die
Hauptarbeit habe ich nur 2ms Zeit, und so mußte
ich möglichst alles rauswerfen, was nicht
wirklich benötigt wurde. Außerdem ist das ein
Monolyt: lsmod gibt nur ein einziges Modul aus,
vme_user, was ich benötigte um auf der kernel
Kommandozeile die Geographie des VME-Busses
einzustellen.

Das ist kein normales motherboard, sondern so
ein industrielles Ding mit einem VME Bus auf
powerpc. Das ist bei der Entwicklung bitter,
denn valgrind/helgrind funktionieren auf
powerpc nicht, und races machen einem das
Leben wirklich schwer.

Der Anbieter des boards wirbt zwar mit Linux
Unterstützung, welche aber völlig unbrauchbar
war. Er wiederholte nur, daß Linux Mist und OS9
das einzig Wahre sei. Aber Windows findet er
auch ganz toll. Unterstützung, die mich weiter
gebracht hätte, hab ich da keine bekommen.

Das Debian war von embedded debian, doch wurde
dieses Projekt später eingestellt. Auch das
verkompliziert ein update.

So ein board support package ohne die internen
Infos finde ich sehr schwierig und Zeit
aufwendig. Allein, ohne Hilfe ein .dtb zu
schreiben ist ein langes Ratespiel. Daß es am
Ende mit dem Kernel 3.8.0 funktionierte war
eher Zufall, denn es funktionierte aus allen
Versionen zwischen 3.4.57 bis 3.8.13 nur mit
dieser einen. Begonnen hatte ich im November
2012, es funktionierte rund aber erst im März
2013.

Da ich nun eine Lösung hatte und unter heftigem
Zeitdruck stand, hab ich's einfach dabei
belassen. Und das rächt sich jetzt natürlich,
denn nach 7 Jahren mich neu reindenken ist auch
nicht ohne.

> Und warum ein RealTime-Patch ich hab bis
> jetzt immer nur gelesen(!) das es mehr
> Probleme als Lösungen schafft.

RT ist drin, weil ich es brauche. Es gibt einen
Block von Arbeiten der unbedingt alle 2ms
wiederholt werden muß. Ich hab das so
getrimmt, daß es in 1ms gemacht werden kann und
mir damit etwa 50% reserviert.

Das einzige Problem mit rt von dem ich schon
seit Anfang an (2012) wußte ist, daß syncs von
dirty pages auf dem FS die RT Prioritäten nicht
respektiert. Es war immer schon einfach das zu
sehen. Ich brauche nur massiv Daten in Dateien
ausgeben. Dann geht die Last exponentiell
rauf. Doch bis vor kurzem (und immer noch auf
nur einer Maschine) konnte ich geringe Daten
ohne Probleme ausgeben, denn offenbar war meine
50% Reserve ausreichend. Jetzt reicht die
kleinste Kleinigkeit um aus der Kurve zu
fliegen.

> Und NFSv3 auf der einen und NFSv4 auf der
> anderen Seite, was meinst du damit genau?

Das Board hat keine eigene Festplatte ist also
der client und kann nur v3. Auf der anderen
Seite ist ein generischeres (aber auch
industrielles) board mit Intel Architektur und
einem moderneren Kernel. Der kann v4 und will
dies per default auch tun; erst wenn man ihn
auf v3 runter zwingt funktioniert es.

Aber mit einem OS zu streiten (es zu irgendwas
zu zwingen, was es nicht freiwillig will), ist
häufig Anfang von Problemen. Und so hab ich
diesen Umstand erwähnt. Das hat aber bis vor
kurzem auch problemlos geklappt.

> Um zu sehen was der Kernel und damit das
> System macht, brauchst du perf, das Kommando
> wäre dann 'perf top' das zeigt die an welche
> Calls gemacht werden und und mit etwas Hilfe
> von deiner Suchmaschine weisst du auch was
> dieser Call genau macht und kannst so
> überlegen wo/ob da der Falschenhals ist bzw
> was dort die Last verursacht

The sys_perf_event_open() syscall returned with
38 (Function not implemented).

Und ohne einen neuen Kernel zu kompilieren (was
eben nicht geht), wird sich das wohl eher nicht
ändern.

Die Sache ist, daß ich da auch nicht viel
Hoffnung habe, eine Lösung zu finden. Wie schon
gesagt, top zeigt alle Prozesse korrekt an, und
keiner dieser Prozesse dreht höher als er soll.
Die Summen stimmen ganz einfach nicht zusammen.

Das subject von diesem thread bezog sich
darauf, daß ich wissen wollte, was da hinter
den Kulissen abgeht, mir das timing versaut und
in der eigentlichen Prozesstabelle nirgends
auftaucht. Mittlerweile denke ich, es ist
nur das Schreiben in Dateien zu sein. Das ist
aber bitter für mich, denn Fehler, die einmal
die Woche auftreten, ohne Logdatei zu jagen
erfordert hellseherische Fähigkeiten.

Zur Zeit (im Normalfall) hab ich ein loadavg
von 0.79; der RT Prozess hat insgesamt 62% CPU
(zwei Kerne) und für "us" werden 21.2, für "sy"
4.2 % CPU angezeigt. Wenn ich mir die Last pro
thread anzeigen lasse, komme ich für den RT
thread (der ist auf eine CPU fest gelegt) auf
irgendwas zwischen 48.9% und 51.2%, die anderen
threads schlafen die meiste Zeit, können aber
sehr kurzfristig etwas höher gehen.

Wenn es dann schief läuft, dann sehe ich für
"sy" und "us" Zahlen in etwa der gleichen
Größenordnung oder höher, der loadavg geht dann
mit der Zeit bis auf etwa 1.9 und da bleibt er
dann: er geht nicht runter, aber auch nicht
weiter rauf. Also nicht exponentiell wie es
passiert, wenn die Zyklenzeit zu kurz wird. Die
Last der threads ist dann aber weiter normal:
der RT-thread rund um die 50%, die anderen beim
Schlafen und sehr kurzfristig etwas höher.

Damit bin ich mir sicher, daß dies etwas ist,
was ich im kernel auslöse, nicht aber im
eigenen Prozess.

Unverständlich ist mir, daß die Last manchmal
bei "sy" und manchmal bei "us" auftritt, eine
Änderung aber erst nach einem reboot (glaube
ich). Wenn immer genau die gleiche Software
läuft, warum ist die Last manchmal beim System
und manchmal beim Userprozess? Wenn eine
Ursache für eine höhere Last verschwindet,
warum sinkt dann die Last nicht wieder?

Während ich diese Anwort schreibe (die Zahlen
hab ich von laufenden Systemen abgetippt) ist
mir etwas aufgefallen, was nicht neu sein kann:
Auf der einen Maschine, die eigentlich immer gut
funktioniert, habe ich in der Kopfzeile von top
nur 1 Zeile, die mit "%CPU(s) beginnt, auf den
anderen Maschinen sind da 2 davon.
Also, bei der "guten":

    top - 11:56:25 ...
    Tasks: 61 total, 1 running...
    %CPU(s): 20.0 us...
    KiB Mem: 2074168...
    KiB Swap: 0 total...

Bei allen anderen:

    top - 11:56:25 ...
    Tasks: 61 total, 1 running...
    %CPU(s): 20.0 us...
    KiB Mem: 2074168...
    %Cpu(s): 27.0 us...

Ich vermute, daß da die Swap-Zeile fehlt, weil
der Kopf von top eben nur 4 Zeilen hat. Wo aber
könnte die zweite CPU-Zeile her kommen? Beide
Maschinen haben das gleiche disk Image, und
beim top verwende ich bloß H um zur Anzeige von
der Thread Last zu kommen.

Vielleicht könnte ich das Problem ja lösen,
wenn ich heraus finden könnte, was die eine
Maschine, welche funktioniert, von den anderen
unterscheidet. Danach habe ich wochenlang
gesucht, aber nichts gefunden.

Der VME-Crate ist identisch und kann auch
ausgetauscht werden.

Die VME Karte (dieses board) verwendet uboot.
Ich habe mir per printenv die ganz
Konfiguration herauskopiert und auf eine andere
Karte geschrieben, sodaß auch das uboot
identisch sein muß.

Mit lshw habe ich alle Hardware verglichen.

Das Betriebssystem mit all seinen
Konfigurationen kommt über ein disk image;
dabei gibt es nur eine einzige Änderung: Die
Konfiguration für die Maschine in der die Karte
steckt (einige haben mehr oder weniger Achsen,
die länger oder kürzer sein können, etc.).

Beim vorigen Setup war dies ein normales
Ethernet Netzwerk, sodaß die Karten
unterschiedliche IPs brauchen. Da das mit
point-to-point nun isoliert ist, wird nicht
einmal mehr der IP oder hostname geändert.
Worin noch könnte ein Unterschied bestehen? Es
muß ihn ganz offensichtlich geben, aber ich
sehe ihn nicht.

Weitere Fragen beantworte ich natürlich gerne.
Sollte ich noch nicht genügend über die
Änderung geschrieben haben, ab welcher die
Probleme anfingen:

Auf diesem board: Es gibt nun eine andere
Netzwerkverbindung, welche point-to-point zum
Rechner geht, der die Festplatte hat. Ansonsten
gab es kleinere bug fixes, die aber den
2ms-Zyklus nicht betrafen und auch nicht OS
Relevantes tun. Über NFS werden über das root
file system selbst nur Konfigurationen der
Maschine (Achsen, etc.) und gewisse logs
übertragen. Die Operationen werden durch
UDP-Pakete ausgelöst, die Rückmeldungen sind
auch UDP. Das dabei verwendete Protokoll hat
sich seit 2012 nicht geändert.

Früher war auf der Seite mit dem NFS-Server ein
Debian mit einem Kernel 3.8.x (der war damals
aktuell), jetzt ist es ein 4.9.0; die Netzwerk
Konfiguration ist natürlich auch entsprechend
angepaßt worden. Das Netzwerk Kabel ging früher
über einen switch, jetzt ist sie direkt.

Total falsch kann ich das alles nicht gemacht
haben, denn ich habe ja eine Maschine, bei der
trotz dieser Änderungen alles so funktioniert
wie zuvor. Aber eben nur eine; alle anderen
machen die beschriebenen Faxen.

Reply | Threaded
Open this post in threaded view
|

Re: Top, Userprozesse und Systemprozesse

Martin Reising-6
On Thu, Jun 06, 2019 at 12:49:25PM +0200, ternaryd wrote:

> On Thu, 06 Jun 2019 10:40:31 +0200
> Stefan K <[hidden email]> wrote:
>
> > Und NFSv3 auf der einen und NFSv4 auf der
> > anderen Seite, was meinst du damit genau?
>
> Das Board hat keine eigene Festplatte ist also
> der client und kann nur v3. Auf der anderen
> Seite ist ein generischeres (aber auch
> industrielles) board mit Intel Architektur und
> einem moderneren Kernel. Der kann v4 und will
> dies per default auch tun; erst wenn man ihn
> auf v3 runter zwingt funktioniert es.
>
> Aber mit einem OS zu streiten (es zu irgendwas
> zu zwingen, was es nicht freiwillig will), ist
> häufig Anfang von Problemen. Und so hab ich
> diesen Umstand erwähnt. Das hat aber bis vor
> kurzem auch problemlos geklappt.

Meine Erfahrung mit NFSv4 war das es für Programme wie libreoffice
weniger Probleme gab, allerdings war es für $HOME mit den üblichen DE
(Gnome, KDE und Unity) ohne .cache, .local/share/Trash, den
Browser-sqlite-datenbanken, .groovy, .gradle, .idea, .eclipise ...
fast unbrauchbar.
Mit NFSv3 (hard,tcp) war das Ganze wieder brauchbar.

munin zeigt bei NFS Server ca. 21 verschiedene Funktion und bei NFSv4
Server ca. 37 verschiedene Funktionen.

Ich würde auf den NFS-Clients mal testweise die Optionen

  nfsvers=3,tcp,noacl,nolock
 
verwenden um NFSv4-, ACL- und Lock-Probleme aus zu schließen.


> Beim vorigen Setup war dies ein normales
> Ethernet Netzwerk, sodaß die Karten
> unterschiedliche IPs brauchen. Da das mit
> point-to-point nun isoliert ist, wird nicht
> einmal mehr der IP oder hostname geändert.
> Worin noch könnte ein Unterschied bestehen? Es
> muß ihn ganz offensichtlich geben, aber ich
> sehe ihn nicht.

Wenn die NFS-Optionen keine Verbesserung bringen, würde ich zusätzlich
die Umstellung auf PtP wieder Rückgängig machen.
Gefühlt ist PtP und NFS keine alltäglich Kombination und damit eine
weitere mögliche Problemquelle.

Reply | Threaded
Open this post in threaded view
|

Re: Top, Userprozesse und Systemprozesse

ternaryd
On Fri, 7 Jun 2019 00:05:32 +0200
Martin Reising <[hidden email]>
wrote:

> Meine Erfahrung mit NFSv4 war das es für
> Programme wie libreoffice weniger Probleme
> gab, allerdings war es für $HOME mit den
> üblichen DE (Gnome, KDE und Unity)
> ohne .cache, .local/share/Trash, [...]

Ich habe auf dem kritischen Board nur eine
Datei mit Logausgaben die geschrieben werden.
Auf dem Rechner mit Festplatte sind zwei
Prozesse, die zwei weitere Dateien ins gleiche
Verzeichnis geschrieben hatten. Es hat
geholfen, das in ein anderes Verzeichnis
um zu lenken. Gelesen wird das fast nie, nur
bei der Fehlersuche, und da nur einmal, weil
ich mir die Logs dann auf einen schnelleren
Rechner kopiere. Die Menge kann ich über Filter
einstellen. Wenn ich's übertreiben will kann
ich auf ein paar Giga pro Stunde kommen, im
Normalfall sind es vielleicht ein paar hundert
Mega in 6 Monaten. Das kommt dann zeitlich
ziemlich konstant.

Ist das eine eher günstige oder ungünstige
Konstellation?

> Mit NFSv3 (hard,tcp) war das Ganze wieder
> brauchbar.

Ich weiß jetzt nicht auswendig, welche Optionen
ich gesetzt habe. Werde das morgen prüfen und
bei Unterschieden definitiv Tests machen. Was
mich halt ärgert ist, daß ich eine Maschine
habe, die das problemlos macht, und alle
anderen nicht. Die Zeilen in /etc/export
bzw. /etc/fstab sind aber identisch (und die
Kernel Kommandozeile vom Client).

> munin zeigt bei NFS Server ca. 21
> verschiedene Funktion und bei NFSv4 Server
> ca. 37 verschiedene Funktionen.

Mir ist eigentlich keine übermäßige Netzwerk
Aktivität aufgefallen; Steuerungsbefehle kommen
über UDP, und da gab es eigentlich nie
merkliche Verzögerungen. So frage ich mich
eher, welcher dieser Funktionen nun eine
Operation auslösen, die auf Client-Seite die
CPU in die Wolken dreht. Werde morgen ein wenig
mit munin spielen.

> Ich würde auf den NFS-Clients mal testweise
> die Optionen nfsvers=3,tcp,noacl,nolock
> verwenden um NFSv4-, ACL- und Lock-Probleme
> aus zu schließen.

Ich werde das vergleichen. Da aber der client
über NFS bootet, steht dies in der
Kommandozeile für den Kernel; nur das zweite
Verzeichnis ist dann auf /etc/fstab

> Wenn die NFS-Optionen keine Verbesserung
> bringen, würde ich zusätzlich die Umstellung
> auf PtP wieder Rückgängig machen.

Das ist nicht ganz trivial, denn ich muß diese
einzige Verbindung als Netzwerk isolieren,
damit von einem lokalen Netzwerk, welches
potentiell eine ähnliche Maske hat, keine
Querschläger dazwischen kommen können. Und eine
Firewall würde ich auf solchen Maschinen
vermeiden wollen. Schließlich hängt niemand
Werkzeugmaschinen ins Internet.

> Gefühlt ist PtP und NFS keine alltäglich
> Kombination und damit eine weitere mögliche
> Problemquelle

Hm. Ganz kann ich das nicht nachvollziehen.
Wenn ein Ping durchgeht, wenn ich ssh per TCP
problemlos machen kann, und wenn die Steuerung
mit UDP auch keinerlei Probleme macht, was
könnte NFS wollen, das ihm dabei fehlt und
dadurch dazu führt, daß die CPU Last hoch
fährt? Ich hätte erwartet, daß NFS sich um die
Netzwerkkonfiguration gar nicht kümmert. Das
schickt Pakete ab und hofft auf deren Ankunft.
Wie ist das bei NFS anders als bei anderen?

Was ich mich hier aber frage ist zweierlei:
Warum kann ich den Unterschied zwischen der
funktionierenden Maschine und den anderen nicht
finden, und ob das wirklich mit Netzwerk zu tun
hat, oder doch nur irgendwie mit dem Kernel
(und wenn dem so wäre, wie).

Reply | Threaded
Open this post in threaded view
|

Re: Top, Userprozesse und Systemprozesse

Martin Steigerwald
In reply to this post by Rolf Reintjes
Rolf Reintjes - 05.06.19, 23:28:

> Am 28.05.2019 um 12:02 schrieb ternaryd:
> > 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.
>
> Die einzige Idee, die mir dazu eingefallen ist: mal htop anstatt top
> verwenden und damit rumspielen.
>
> Bist du in der Sache denn schon irgendwie weiter gekommen?

Ich halte für wichtig, sich erst mal ein konkretes, systematisches (!)
Vorgehen zu überlegen, anstatt auf gut Glück rumzustochern. Ich verweise
dazu auf die systematischen Methoden, die Brendan Gregg in seinem Buch
"Systems Performance" erwähnt¹.

Die USE-Methode² ist bei Resourcen-Auslastung gut, nur ist mir aus dem
Mailinglisten-Thread nicht mal klar, inwiefern da eine Resource wirklich
ausgelastet ist.

Da ich vom Lesen des Threads nicht den Eindruck hatte, dass die CPUs
wirklich ausgelastet sind – stimmt das? – wäre auch die On/Off-CPU-
Analyse eine Idee³.

Ansonsten bliebe das Vergleichen fortzusetzen, jedoch auf systematische
Weise: Erst mal ein Schaubild machen, was es alles für Komponenten gibt
im System und dann mit Checkliste vergleichen, um sicherzustellen, dass
du auch wirklich an allen dir bekannten Stellen geschaut hast. Auch so
könnte das sehr aufwendig sein. Und dann stellt sich die Frage, ob sich
der Aufwand lohnt.

Eine zündende Idee hab ich nicht, da perf auf den Systemen offenbar nicht
funktioniert, und es bislang danach klingt, dass das irgendwie mit
Kernel und/oder Hardware zu tun hat. Hier dennoch mal ein paar Ideen:

Sysdig wäre noch eine Idee, das braucht aber ein Extra-Kernel Modul (in
Debian ab 9 als dkms-Paket enthalten) und scheidet deshalb
wahrscheinlich auch aus.

Es wäre noch eine Idee mit atop[4] mal drauf zu schauen, da es System-
Aspekte etwas ausführlicher anzeigt als top und atop. Atop hat auch die
Möglichkeit, Aufzeichnungen zu machen und sich diese später anzuschauen
oder mit atopsar zu analysieren. Es nutzt das Process Accounting des
Kernels und bekommt daher auch mit, was zwischen Mess-Intervallen
passiert – falls ein Prozess unterhalb einer Sekunde kurzfristig
Maximal-Last erzeugt.

Vielleicht funktioniert auch latencytop auf den Boards. Das braucht aber
CONFIG_LATENCYTOP im Kernel. Das dient dazu, anzuzeigen, welche Prozesse
auf welche Kernel-Operationen warten. Im Debian-Kernel 4.19 ist das
standardmäßig nicht aktiv.


[1] http://www.brendangregg.com/sysperfbook.html

[2] http://www.brendangregg.com/usemethod.html

[3] http://www.brendangregg.com/offcpuanalysis.html

[4] https://atoptool.nl/

https://blog.proact.de/2014/10/28/echtzeit-monitoring-welches-top-darfs-denn-sein/

https://www.linux-community.de/ausgaben/linuxuser/2014/08/top-htop-atop-und-glances-im-vergleich/

Ciao,
--
Martin


Reply | Threaded
Open this post in threaded view
|

Re: Top, Userprozesse und Systemprozesse

Christian Knoke
In reply to this post by ternaryd
ternaryd schrieb am 07. Jun um 00:50 Uhr:

> Was ich mich hier aber frage ist zweierlei:
> Warum kann ich den Unterschied zwischen der
> funktionierenden Maschine und den anderen nicht
> finden, und ob das wirklich mit Netzwerk zu tun
> hat, oder doch nur irgendwie mit dem Kernel
> (und wenn dem so wäre, wie).

Wenn du das Gefühl hast, dass der neue Kernel nicht so gut läuft wie der
alte, mach doch erstmal ein paar Benchmarktests mit beiden Versionen.  Es
kann ja sein, dass der neue Kernel dein spezielles Board nicht mehr so gut
unterstützt.

Gruß
Christian

--
http://cknoke.de

Reply | Threaded
Open this post in threaded view
|

Re: Top, Userprozesse und Systemprozesse

ternaryd
In reply to this post by Martin Steigerwald
On Fri, 07 Jun 2019 11:04:33 +0200
Martin Steigerwald <[hidden email]> wrote:

> Ich halte für wichtig, sich erst mal ein
> konkretes, systematisches (!) Vorgehen zu
> überlegen, anstatt auf gut Glück
> rumzustochern.

Ich glaube nicht, daß ich herumstochere.
Außerdem ist die Architektur des Aufbaus bewußt
so simpel wie möglich gehalten. So viele
Komponenten gibt es da nicht.

> Ich verweise dazu auf die systematischen
> Methoden, die Brendan Gregg in seinem Buch
> "Systems Performance" erwähnt¹.

Ich darf nicht verschwenderisch werden, aber
die Leistung der Karten ist ausreichend, sodaß
ich mir etwa 50% Reserve halten kann. Selbst
wenn die Gesamtlast steigt, die angezeigte Last
betrifft nicht meine Prozesse.

> Da ich vom Lesen des Threads nicht den
> Eindruck hatte, dass die CPUs wirklich
> ausgelastet sind – stimmt das? – wäre auch die
> On/Off-CPU- Analyse eine Idee³.

Das ist richtig. Der prioritäre rt-thread ist
auf 50% getrimmt und läuft fast deterministisch
und konstant. Die anderen threads schlafen die
meiste Zeit, wenn sie aber was zu tun haben,
bleibt ihnen der der 50%. Genauer genommen
bleibt ihnen 150%, denn das board hat 2 CPU
kerne, und der rt-thread ist auf einen Kern
fixiert.

> Ansonsten bliebe das Vergleichen fortzusetzen,
> jedoch auf systematische Weise: Erst mal ein
> Schaubild machen, was es alles für Komponenten
> gibt im System

Wenn zwei System identisch aufgebaut werden,
also die gleiche Hardware vom gleichen
Fabrikanten haben und die Software von disk
images kopiert wird, und eines funktioniert und
das andere nicht, gehen mir die Ideen relativ
schnell aus :-( Deswegen bleibt mir nur, das
funktionierende System zu vergessen und den
Fehler auf dem nicht funktionierenden System zu
suchen.

Zur Zeit halte ich die Vorschläge von Martin
Reising für die heißeste Spur, die ich gerade
versuche zu verfolgen. Denn tatsächlich hat das
Theater begonnen, als auf dem zweiten Rechner,
von welchem das root-NFS kommt, NFS-v4 gekommen
ist, und Martin hat einige Optionen genannt,
die bei mir nicht vorkommen. Da ich diese
Optionen aber über die Kernel Kommandozeile im
Uboot setzen muß, bin ich noch am suchen, wie
da die richtige Syntax laute.

[...] Aufzeichnungen [...] Process Accounting

Jeder Versuch etwas zu schreiben, beschleunigt
den Verfall zur Unverwendbarkeit. Indem ich auf
meine eigenen Aufzeichnungen verzichte habe ich
diesen Verfall hinausgezögert (aber nicht
verhindert).

> latencytop auf den Boards.

Da dies ein RT Kernel ist, ist mir die Latenz
ein wichtiger Faktor. Sie wurde auf etwa 100us
getrimmt. Geht sie davon deutlich weg, kann man
das an der Maschine hören (klingt sehr übel).

> Im Debian-Kernel 4.19

Das ist Kernel 3.8.0, leider unveränderbar, und
nicht Standard Debian, das (zumindest damals)
keinen RT-Kernel angeboten hat.

Trotzdem Danke

Reply | Threaded
Open this post in threaded view
|

Re: Top, Userprozesse und Systemprozesse

ternaryd
In reply to this post by Christian Knoke
On Fri, 7 Jun 2019 11:40:53 +0200
Christian Knoke <[hidden email]> wrote:

> Wenn du das Gefühl hast, dass der neue Kernel
> nicht so gut läuft wie der alte, mach doch
> erstmal ein paar Benchmarktests mit beiden
> Versionen.

Ich fürchte, da ist was durcheinander gekommen.
Es gibt ein board (VME), welches einen Kernel
hat, den ich nicht ändern kann. Es hat auch
keinen Massenspeicher, sodaß hier ein root-NFS
verwendet wird.

Was sich geändert hat ist der Kernel vom
zweiten Rechner, von welchem der erste sein
root-NFS holt. Auf diesem Rechner läuft auch
eine graphische Oberfläche unter QT. Das war
ursprünglich QT4, sollte nun aber QT5 werden.
Außerdem fand ich es nicht schlimm, da ein
aktuelle(re)s Debian zu haben. Daß das aber per
default NFS-v4 hat, und daß NFS-v4 server mit
NFS-v3 client nicht freundlich kooperieren,
wußte ich eingangs nicht. Nur kann ich nicht
zurückrudern, denn sonst geht das GUI nicht
mehr, welches ja nun QT5 ist.

Dieses GUI verwendet aber ein Netzwerkprotokoll
um seine Befehle an die VME-Karte zu senden,
und dieses hat sich absolut nicht geändert.
Damit kann es der VME-Karte auch egal sein, ob
da QT4 oder QT5 läuft, sie bekommt ja doch
nichts davon mit. Das mit NFS-v3 und NFS-v4 ist
da ein ganz anderer Fall.

Trotzdem Danke

Reply | Threaded
Open this post in threaded view
|

Re: Top, Userprozesse und Systemprozesse

ternaryd
In reply to this post by Martin Reising-6
On Fri, 7 Jun 2019 00:05:32 +0200
Martin Reising <[hidden email]>
wrote:

> Ich würde auf den NFS-Clients mal testweise
> die Optionen
>   nfsvers=3,tcp,noacl,nolock
>  
> verwenden um NFSv4-, ACL- und Lock-Probleme
> aus zu schließen.

Wie gesagt, das ist ein nfs root fs, sodaß die
NFS Optionen schon auf der Kommandozeile für
den Kernel stehen müssen. Diese lautet:

    [    0.000000] Kernel command line: \
    vme_tsi148.geoid=1 root=/dev/nfs \
    nfsroot=172.23.128.122:/srv/cnc,v3,tcp,noacl,nolock\
    nfsrootdebug rw keep_bootcon panic=1 \
    console=ttyS0,115200 \
ip=172.23.128.121:172.23.128.122:172.23.128.122:255.255.255.252:cnc:eth0:off

Scheinbar muß man "nfsvers=3" hier mit "v3"
schreiben.

Diese Tests habe ich immer parallel auf der
Maschine gemacht, bei der der Fehler nicht
auftritt, und einer wo schon. Die Maschine,
auf welcher der Fehler nicht auftritt (und alle
anderen vor dieser Änderung) hatten als
einzigen Unterschiede nicht "tcp,noacl,nolock"

Sicherheitshalber habe ich das Analoge auch in
/etc/fstab auf dem client und in /etc/exports
auf dem server gemacht:

client fstab:

    172.23.128.122:/srv/cnc / nfs \
    rw,nodev,exec,suid,auto,async,nfsvers=3,tcp,noacl,nolock\
    0 0
    172.23.128.122:/home/data /home/data nfs \
    rw,nodev,exec,suid,auto,async,nfsvers=3,tcp,noacl,nolock\
    0 0

server export:

    /srv/cnc \
    172.23.128.121/32(rw,no_root_squash,sync,no_subtree_check,fsid=0)
    /home/data \
172.23.128.121/32(rw,no_root_squash,sync,no_subtree_check,fsid=1,anonuid=1001,anongid=1001)

Leider tritt der Fehler immer noch auf. Gleich
nach dem boot kann ich sehen, daß die Maschine
mit dem Fehler eine in etwa 20% höhere Last
hat, wofür ich absolut keinen Grund finden
kann. Das ist aber noch nicht kritisch. Nach
etwa 24h dreht die CPU dann auf etwa 1.3 hoch,
was so eine Art Schwellwert ist; ab hier treten
Instabilitäten auf. Noch einmal 24 Stunden, und
die Last geht auf vielleicht 1.9, die Maschine
ist nun ständig instabil. Wenn ich es noch
länger lasse, geht es sehr langsam aber doch
weiter hoch; nach einer Woche kann ich dann
auch 2.5 sehen.

Was könnte ich noch probieren?

> Wenn die NFS-Optionen keine Verbesserung
> bringen, würde ich zusätzlich die Umstellung
> auf PtP wieder Rückgängig machen. Gefühlt
> ist PtP und NFS keine alltäglich Kombination
> und damit eine weitere mögliche Problemquelle.

Könntest du das hier ein wenig erläutern, denn
ich kann das nicht ganz nachvollziehen. Die
die Maschine, die immer funktioniert, hat genau
die gleiche Netzwerkkonfiguration. Alle anderen
Netzwerkoperationen scheinen ganz normal zu
funktionieren.

Danke!