Hoher load / CPU durch ksoftirqd

Cerox

New Member
Ich habe auf einem Server seit ~14:30 Uhr heute das Problem, dass der Load bei 15 oder höher liegt. Verantworlich dürfte dafür ksoftirqd sein.
Der Server ist mit OpenVZ virtualisiert und der Performanceeinbruch ist selbst auf der Shell zu spüren.
Was kann man dagegen tun bzw. woher kommt diese plötzliche Auslastung?

Top:
Code:
top - 18:58:26 up 279 days,  3:10,  3 users,  load average: 15.33, 15.12, 15.26
Tasks: 268 total,   8 running, 260 sleeping,   0 stopped,   0 zombie
Cpu(s):  7.2%us,  1.3%sy,  1.4%ni,  0.0%id,  0.0%wa,  0.0%hi, 90.1%si,  0.0%st
Mem:   8173812k total,  5472008k used,  2701804k free,   542716k buffers
Swap:  8001936k total,    82788k used,  7919148k free,  1500460k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
   13 root      20   0     0    0    0 R   88  0.0  17435:47 ksoftirqd/3
    7 root      20   0     0    0    0 R   74  0.0  17934:19 ksoftirqd/1
14958 2016      20   0 59160  25m 4352 S   53  0.3   0:07.19 php5-cgi
   10 root      20   0     0    0    0 R   49  0.0  17868:51 ksoftirqd/2
18236 2013      20   0 84528  49m 3268 S   31  0.6   0:51.66 php5-cgi
    4 root      20   0     0    0    0 R   21  0.0  17243:05 ksoftirqd/0
12227 root      20   0 40952 3256 2244 R   21  0.0  27:24.55 ssh
11643 root      20   0 70460 3408 2672 S    7  0.0   1:15.29 sshd
13937 www-data  20   0  255m  29m 1756 S    5  0.4   9:26.22 apache2
13938 www-data  20   0  317m  72m 1748 S    5  0.9  10:07.31 apache2
   15 root      20   0     0    0    0 S    5  0.0  12:12.56 events/0
18682 www-data  20   0 30516 9984 3708 S    4  0.1   0:01.38 apache2
31445 sshd      20   0 1734m 1.6g 4616 S    3 20.5 228:19.56 mysqld
15637 www-data  20   0  230m  10m 1728 S    3  0.1   4:19.87 apache2
19094 smmsp     25   5  4648 2936 1604 R    2  0.0   0:00.07 perl
10516 root      20   0 70460 3408 2672 S    2  0.0   2:23.27 sshd
31495 110       20   0  3708  864  576 S    2  0.0   5:28.92 nrpe
 2615 nagios    20   0 24700  580  540 S    2  0.0  13:29.37 nrpe
10538 root      20   0 19208 1556 1016 S    1  0.0   0:58.28 top
18761 2013      20   0 75488  40m 3260 S    1  0.5   0:14.58 php5-cgi
18803 root      20   0 19204 1516 1016 R    1  0.0   0:01.68 top
14957 2016      20   0 50856  16m 3412 R    1  0.2   0:07.95 php5-cgi
18762 2013      20   0 75520  40m 3252 S    1  0.5   0:16.95 php5-cgi
12291 1000      20   0  438m 346m 1748 S    0  4.3   2618:06 java

Edit:
Im Anhang das Bild von Nagios
 

Attachments

  • image.png
    image.png
    16.8 KB · Views: 228
Last edited by a moderator:
Du hast sehr hohe si, also Swap IN.
In anderen Worten; dein Serverli muss massig auf die Platte schreiben weil er nicht genug Platz im RAM hat um seiner Swapiness und dem RAM-Bedarf gerecht zu werden.

Das muss allerdings nicht unbedingt von dir kommen -zumindest deine Beschreibung klingt als ob du auf einem shared Host mit anderen Kunden sitzt; evtl belastet ein anderer das System so weit dass du in Mitleidenschaft gezogen wirst sobald du etwas Belastung ausübst.



[Edit]
Korrektur: (kA wie ich damals drauf kam)
SI ist natürlich NICHT Swap-In sondern Software-Interrupts
 
Last edited by a moderator:
Hat sich erledigt. Es wurde eine neue IP auf den Container geschaltet und dann hat die Netzwerkkarte wohl rumgesponnen.

Das mit dem si ist mir aber noch nicht ganz klar, er hatte doch noch genug freien Ram (siehe top Ausgabe unten).
Wäre nett wenn mir das jemand erklären könnte, des reinen Wissens wegen :)
 
Sorry, wenn ich den Thread hochhole.
Aber ich habe genau dasselbe Problem:

Ich füge eine neue IP einem VZ-Container (vzctl set ID --ipadd IP --save) hinzu, und der ksoftirqd springt in die Höhe, alle 12 Threads sind mit SI 100% ausgelastet.
Sehr seltsam.
Folgendes wird angezeigt:

Code:
root@nexus:~# vzctl set 101 --ipadd 1.1.1.1 --save
Adding IP address(es): 1.1.1.1
Execution timeout expired
Got signal 15
CT configuration saved to /etc/pve/openvz/101.conf
(1.1.1.1 ist pseudo)

Könnte das mit dem PVE-Filesystem /etc/pve (ist gemounted) zusammenhängen?

Den Container killen behebt das Problem, sollte aber nicht das Ziel sein so..
 
Last edited by a moderator:
Back
Top