Re: Top, Userprozesse und Systemprozesse
On Thu, 06 Jun 2019 10:40:31 +0200
Stefan K <shadow_7@gmx.net> 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 to: