load avarage 10
load avarage 10
Hallo,
wie kann man die ursache vom zu hohen load avarage ermitteln?
Ich habe hier den Wert 10, 10, 10, aber der einzige Prozess welcher Ziffern > 0 angibt ist Java mit CPU und Mem von ebenfallls jeweils 10.
Gruß martin123
wie kann man die ursache vom zu hohen load avarage ermitteln?
Ich habe hier den Wert 10, 10, 10, aber der einzige Prozess welcher Ziffern > 0 angibt ist Java mit CPU und Mem von ebenfallls jeweils 10.
Gruß martin123
keine Vorschläage - mehr Infos
Biite um Ideen. Kollege hatte sogar rebootet... keien Änderung:
Komisch nur das gleich Zobies kommen
LG martin123
Komisch nur das gleich Zobies kommen
Code: Select all
~ iostat -m -x 1 10
Linux 2.6.32-5-amd64 (mein-server) 12.06.2014 _x86_64_ (4 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0,50 0,00 0,74 0,00 0,00 98,76
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sda 0,00 1,00 0,00 3,00 0,00 0,02 10,67 0,00 0,00 0,00 0,00
Code: Select all
Tasks: 188 total, 1 running, 177 sleeping, 0 stopped, 10 zombie
Cpu0 : 2.7%us, 0.3%sy, 0.0%ni, 96.7%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
Cpu1 : 0.6%us, 0.3%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 0.3%us, 0.3%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.3%us, 1.0%sy, 0.0%ni, 98.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8200036k total, 1196808k used, 7003228k free, 41944k buffers
Swap: 5859320k total, 0k used, 5859320k free, 227808k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2043 portal 20 0 1673m 737m 18m S 4 9.2 4:49.36 java
1822 root 20 0 63324 1916 1204 S 0 0.0 0:02.33 nmbd
20450 root 20 0 19176 1440 1020 R 0 0.0 0:00.02 top
1 root 20 0 8356 816 684 S 0 0.0 0:01.09 init
Code: Select all
~# df -h
Dateisystem Size Used Avail Use% Eingehängt auf
/dev/sda1 563M 316M 219M 60% /
tmpfs 4,0G 0 4,0G 0% /lib/init/rw
udev 4,0G 124K 4,0G 1% /dev
tmpfs 4,0G 0 4,0G 0% /dev/shm
/dev/sda2 324M 25M 283M 8% /boot
/dev/sda8 5,5G 159M 5,1G 3% /home
/dev/sda7 7,4G 352M 6,7G 5% /opt
/dev/sda6 11G 157M 11G 2% /tmp
/dev/sda9 13G 3,1G 8,7G 27% /usr
/dev/sda5 17G 4,2G 12G 27% /var
Re: netwerk ?
Hi!
Wenn das Problem von Java kommt, mal mit "ps ax" nachsehen, welches Program es ist, und in dessen Logdatei nachsehen.
Grüße,
hjb
Das ist wenig.martin123 wrote:Und 48 tcp, udp-Verbindungen, sowie 32 unix-sockets ...
Wenn das Problem von Java kommt, mal mit "ps ax" nachsehen, welches Program es ist, und in dessen Logdatei nachsehen.
Grüße,
hjb
Pro-Linux - warum durch Fenster steigen, wenn es eine Tür gibt?
java + cups
Im Prinzip läuft da "nur" eine Java-gestuerte Anwendung für Massendruck mit 2 CUPS- und 20 lp-Prozessen.
Java ist:
/usr/lib/jvm/jdk1.7.0_09/bin/java -XX:MaxPermSize=128M -Xms64m -Xmx1024m
In den /var/log/messages und cups_error.log ist nicht Auffälliges zu entdecken
Gruß martin123
Java ist:
/usr/lib/jvm/jdk1.7.0_09/bin/java -XX:MaxPermSize=128M -Xms64m -Xmx1024m
In den /var/log/messages und cups_error.log ist nicht Auffälliges zu entdecken
Gruß martin123
Ich staune vor allem über die Aussagen in diesem "Unixboard".
Z.B. Zombie-Prozesse erhöhen die Last nicht so. Dazu stelle ich fest: Zombie-Prozesse erzeugen überhaupt keine Last, und sie belegen auch keinen Speicher mehr. Das einzige, was von diesem Prozess noch übrig ist, ist ein Eintrag in der Prozesstabelle, in dem der Exitcode und die PID des Vaterprozesses drinsteht.
Und das ist auch der Grund, warum man einen Zombie-Prozess nicht killen kann, wie ebenfalls dort empfohlen wird. Er ist nämlich schon tot. Das Term-Signal hat er vor langer Zeit bereits bekommen. Die reguläre Methode, einen Zombie loszuwerden ist es, dass der Vaterprozess den Exitcode abfragt, dann legt sich der Zombie zur ewigen Ruhe und ward nie mehr gesehen. Wenn der Vaterprozess das nicht macht, hat offenbar dieser das Problem. Will man die Zombies loswerden, muss man logischerweise deren Vater beenden, dann merkt der Kernel, dass der Exitcode uninteressant geworden ist und wirft die Leichen gleich mit weg.
Janka
Z.B. Zombie-Prozesse erhöhen die Last nicht so. Dazu stelle ich fest: Zombie-Prozesse erzeugen überhaupt keine Last, und sie belegen auch keinen Speicher mehr. Das einzige, was von diesem Prozess noch übrig ist, ist ein Eintrag in der Prozesstabelle, in dem der Exitcode und die PID des Vaterprozesses drinsteht.
Und das ist auch der Grund, warum man einen Zombie-Prozess nicht killen kann, wie ebenfalls dort empfohlen wird. Er ist nämlich schon tot. Das Term-Signal hat er vor langer Zeit bereits bekommen. Die reguläre Methode, einen Zombie loszuwerden ist es, dass der Vaterprozess den Exitcode abfragt, dann legt sich der Zombie zur ewigen Ruhe und ward nie mehr gesehen. Wenn der Vaterprozess das nicht macht, hat offenbar dieser das Problem. Will man die Zombies loswerden, muss man logischerweise deren Vater beenden, dann merkt der Kernel, dass der Exitcode uninteressant geworden ist und wirft die Leichen gleich mit weg.
Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.
Ich mag die Schreie.
Die Antwort
Hallo Leute,
danke Euer regen Beteiligung.
> Was passiert, wenn du das Programm stoppst? Geht dann die Load runter? Bleibt sie nach einem neuen Start niedrig?
Nach einem Reboot (Kollege aus der Windows-Fraktion) war der Load sofort wieder mit dem gleichen Wert da. Die Zombies auch ...
Das Programm hatte ein externer DL geschrieben.
Der Grund war nicht funktionierendes Lock auf nfs-gemountete Dateien.
Das es früher mal locking Probleme mit Exports von BSD-NFS unter Debian gab hatte ich schon mal gehört, diese aber für gefixt gehalten...
> Z.B. Zombie-Prozesse erhöhen die Last nicht so. Dazu stelle ich fest: Zombie-Prozesse erzeugen überhaupt keine Last, und sie belegen auch keinen Speicher mehr.
Das hatte ich auch mal gelernt
bye martin123
danke Euer regen Beteiligung.
> Was passiert, wenn du das Programm stoppst? Geht dann die Load runter? Bleibt sie nach einem neuen Start niedrig?
Nach einem Reboot (Kollege aus der Windows-Fraktion) war der Load sofort wieder mit dem gleichen Wert da. Die Zombies auch ...
Das Programm hatte ein externer DL geschrieben.
Der Grund war nicht funktionierendes Lock auf nfs-gemountete Dateien.
Das es früher mal locking Probleme mit Exports von BSD-NFS unter Debian gab hatte ich schon mal gehört, diese aber für gefixt gehalten...
> Z.B. Zombie-Prozesse erhöhen die Last nicht so. Dazu stelle ich fest: Zombie-Prozesse erzeugen überhaupt keine Last, und sie belegen auch keinen Speicher mehr.
Das hatte ich auch mal gelernt
bye martin123