Blockade beim erstmaligen Starten eines dicken Programms

26/01/2012 - 13:53 von E. Braun | Report spam
Hi,

ich habe gerade ein seltsames Phànomen, welches ich gern abstellen
würde. Auf einem Rechner mit 4 Opterons (6176 SE - 12 Kerne) und 128
GByte Hauptspeicher tritt beim Starten von "großen" Programmen,
sprich: Libre Office, Matlab, Mathematica, Eclipse... eine übermàßig
lange Denkpause von etwa 20 Sekunden bis 1,5 Minuten ein, in der viele
neue Prozesse nicht oder nicht sofort gestartet werden können. D. h.,
"ps" geht z. B. nach einigen Sekunden, aber "top" verzögert sich
lànger, einen Editor wie "jed" kann man gar nicht in der Zeit starten.
Ein im Hintergrund rechnendes Programm bleibt anscheinend stehen. Ein
System konnte ich dafür nicht festellen. Làuft schon ein "top", so
kann man dem Load-Wert beim Erhöhen um etwa 1-3 zuschauen, die bereits
laufenden Prozesse verbrauchen aber nicht mehr CPU. Nach Ablauf der
genannten Zeit geht alles wie üblich weiter. Startet man das Programm
ein zweites Mal, funktioniert auch alles wie normal.

Zumindest an der Platte (LVM auf Hardware-RAID) scheint es nicht zu
liegen, da das parallele Beschreiben und Lesen mittels "dd" den
üblichen Arbeitsablauf nicht weiter beeinflußt.

Verfolgt man einen hàngenden Prozeß mit strace, sieht man, daß er
wàhrend des exexve() wartet:

execve("/data/mathematica70/SystemFiles/Kernel/Binaries/Linux-x86-64/MathKernel",
["/data/mathematica70/SystemFiles/"...], [/* 29 vars */]


Hat jemand eine Idee, was man da machen kann?

Danke, Erik
 

Lesen sie die antworten

#1 Hauke Laging
28/01/2012 - 01:13 | Warnen spam
E. Braun wrote on Donnerstag, 26. Januar 2012 13:53:

4 Opterons (6176 SE - 12 Kerne) und 128 GByte Hauptspeicher



uiuiui


tritt beim Starten von "großen" Programmen,
sprich: Libre Office, Matlab, Mathematica, Eclipse...



Mein erster Gedanke wàre herauszufinden, was die problematischen Programme
gemeinsam haben, was sie von den anderen unterscheidet.


Startet man das Programm
ein zweites Mal, funktioniert auch alles wie normal.



Da dràngt sich der Gedanke auf, dass es etwas mit dem Plattenzugriff zu tun
hat, so dass der Cache das Problem erledigt. Was ist, wenn Du mehrere
betroffene Programme hintereinander startest, haben die dann jeweils einzeln
das Problem, oder tritt das nur beim ersten oder manchen Programmen auf?


Zumindest an der Platte (LVM auf Hardware-RAID) scheint es nicht zu
liegen, da das parallele Beschreiben und Lesen mittels "dd" den
üblichen Arbeitsablauf nicht weiter beeinflußt.



Kann ein partielles Hardwareproblem sein. Eine DLL, die teilweise nicht im
ersten Versuch gelesen werden kann.


Verfolgt man einen hàngenden Prozeß mit strace, sieht man, daß er
wàhrend des exexve() wartet:

execve("/data/mathematica70/SystemFiles/Kernel/Binaries/Linux-


x86-64/MathKernel",
["/data/mathematica70/SystemFiles/"...], [/* 29 vars */]


Hat jemand eine Idee, was man da machen kann?



strace schlüsselt ja die Aktionen des Linkers nicht auf; ich wüsste auch
nicht, dass man ihm das irgendwie beibringen kann. Aber über ldd kann man ja
nachsehen, welche Dateien eingebunden werden. Vielleicht làsst sich so eine
Gemeinsamkeit finden.

Simpler mag es sein (und für die Abrenzung ausreichend), /lib, /lib64,
/usr/lib und /usr/lib64 in eine Ramdisk zu kopieren und die (ro)
drüberzumounten. Wenn die Programme dann sauber starten, lohnt es sich, das
einzugrenzen.

Im Grunde müsste dann aber schon cp scheitern, also cp am besten durch
strace -tt -o laufen lassen, so dass Du hinterher sehen kannst, welche
Dateien lange gebraucht haben.

Wenn das nicht klappt, könntest Du mal per Kernelparameter den benutzen
Speicher drastisch reduzieren, so auf 4 GiB, und vielleicht auch die Anzahl
der verwendeten CPUs/Kerne, um zu testen, ob da vielleicht nur auf Grund
dieser Monsterkonfiguration irgendein Kernelbug aktiviert wird.


CU

Hauke
http://www.hauke-laging.de/ideen/
D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814

Ähnliche fragen