load avarage 10

Software besorgen und anwenden
Antworten
Nachricht
Autor
martin123

load avarage 10

#1 Beitrag von martin123 » 11. Jun 2014 15:16

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

martin123

keine Vorschläage - mehr Infos

#2 Beitrag von martin123 » 12. Jun 2014 8:23

Biite um Ideen. Kollege hatte sogar rebootet... keien Änderung:

Komisch nur das gleich Zobies kommen :?:

Code: Alles auswählen

~ 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: Alles auswählen

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: Alles auswählen

~# 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 
LG martin123

martin123

netwerk ?

#3 Beitrag von martin123 » 12. Jun 2014 8:45

Und 48 tcp, udp-Verbindungen, sowie 32 unix-sockets ...

Benutzeravatar
hjb
Pro-Linux
Beiträge: 3244
Registriert: 15. Aug 1999 16:59
Wohnort: Bruchsal
Kontaktdaten:

Re: netwerk ?

#4 Beitrag von hjb » 12. Jun 2014 10:04

Hi!
martin123 hat geschrieben:Und 48 tcp, udp-Verbindungen, sowie 32 unix-sockets ...
Das ist wenig.

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?

martin123

java + cups

#5 Beitrag von martin123 » 12. Jun 2014 10:43

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

Benutzeravatar
Janka
Beiträge: 3573
Registriert: 11. Feb 2006 19:10

#6 Beitrag von Janka » 12. Jun 2014 12:35

Und die kann ja scheiße programmiert sein, busy-loop. Vermutlich tritt die nur in einem seltenen, schlecht getesteten Fehlerfall auf.

Janka
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.

sojasau
Beiträge: 68
Registriert: 30. Okt 2012 18:20
Wohnort: umme Ecke

#7 Beitrag von sojasau » 12. Jun 2014 20:14

Greetz
sojasau

martin123

loop

#8 Beitrag von martin123 » 12. Jun 2014 20:58

Stecke in nun in der Endlosschleife ?

Benutzeravatar
hjb
Pro-Linux
Beiträge: 3244
Registriert: 15. Aug 1999 16:59
Wohnort: Bruchsal
Kontaktdaten:

#9 Beitrag von hjb » 13. Jun 2014 10:19

Hi!

Was passiert, wenn du das Programm stoppst? Geht dann die Load runter? Bleibt sie nach einem neuen Start niedrig? Wer hat das Programm geschrieben?

Grüße,
hjb
Pro-Linux - warum durch Fenster steigen, wenn es eine Tür gibt?

Benutzeravatar
Janka
Beiträge: 3573
Registriert: 11. Feb 2006 19:10

#10 Beitrag von Janka » 13. Jun 2014 12:28

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
Ich vertonne Spam immer in /dev/dsp statt /dev/null.
Ich mag die Schreie.

martin123

Die Antwort

#11 Beitrag von martin123 » 15. Jun 2014 20:00

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

Antworten