KVM Server nach Update auf i-MSCP v1.2.11 extrem verlangsamt

Curio · Jan 20th 2016

Hallo Leute,

Mein Server: KVM-Server, Debian 7.9 Wheezy, PHP v5.5.30, MySQL v5.5.46, Apache v2.2.22, wird als Web- und Mailserver genutzt.

Nach dem Update von i-mscp 1.2.9 auf die 1.2.10 kam es vereinzelt zu Abbrüchen im E-Mail-Verkehr. Als sich diese Abbrüche dann massierten, habe ich gleich auf die i-mscp Version 1.2.11 aktualisiert, da ich danach die Mailserverkonfiguration eh immer neu durchführe. Die Updatevorgänge erfolgten exakt nach den Vorgaben aus der INSTALL-Datei. I-MSCP-Dienste wurden gestoppt, php-apc wurde aus der packages-wheezy.xml entfernt und i-MSCP Plugins nutze ich nicht.

Nach dem letzten i-mscp Update lief der Server ca. einen halben Tag ohne Probleme, dann traten wieder die Verbindungsabbrüche im E-Mail-Verkehr auf. Gleichzeitig waren aber auch die Webseiten nicht mehr erreichbar. Ich konnte mich zwar per SSH noch mit dem Server verbinden, jedoch extrem verzögert. In der mail.log konnte ich feststellen, dass in den Problemzeiten die Verbindungen an einer nicht funktionierenden Authentifizierung scheiterten. In der Apache2/error.log fand ich jedoch viele Fehlermeldungen, wie diese:

Code

[Tue Jan 19 14:33:11 2016] [alert] i-MSCP Vlogger: Unable to dump tracker: DBI connect('database=imscp;host=127.0.0.1;port=3306','vlogger_user',...) failed: Can't connect to MySQL server on '127.0.0.1' (111) at /usr/local/sbin/vlogger line 493

und im syslog:

Code

Jan 20 16:37:45 srv kernel: [48456.630566] 29810 total pagecache pages
Jan 20 16:37:45 srv kernel: [48456.630567] 27312 pages in swap cache
Jan 20 16:37:45 srv kernel: [48456.630569] Swap cache stats: add 13906369, delete 13879057, find 56737622/58028027
Jan 20 16:37:45 srv kernel: [48456.630570] Free swap = 0kB
Jan 20 16:37:45 srv kernel: [48456.630571] Total swap = 1951740kB
Jan 20 16:37:45 srv kernel: [48456.642406] 1048560 pages RAM
Jan 20 16:37:45 srv kernel: [48456.642409] 33212 pages reserved
Jan 20 16:37:45 srv kernel: [48456.642410] 239770 pages shared
Jan 20 16:37:45 srv kernel: [48456.642411] 983730 pages non-shared
Jan 20 16:37:45 srv kernel: [48456.642412] [ pid ] uid tgid total_vm rss cpu oom_adj oom_score_adj name
Jan 20 16:37:45 srv kernel: [48456.642422] [ 286] 0 286 5312 1 0 -17 -1000 udevd
Jan 20 16:37:45 srv kernel: [48456.642426] [ 399] 0 399 5311 0 0 -17 -1000 udevd
Jan 20 16:37:45 srv kernel: [48456.642429] [ 400] 0 400 5311 0 0 -17 -1000 udevd
Jan 20 16:37:45 srv kernel: [48456.642436] [ 1657] 0 1657 4743 14 0 0 0 rpcbind
Jan 20 16:37:45 srv kernel: [48456.642439] [ 1688] 103 1688 5836 2 0 0 0 rpc.statd
Jan 20 16:37:45 srv kernel: [48456.642443] [ 1702] 0 1702 6324 0 0 0 0 rpc.idmapd
Jan 20 16:37:45 srv kernel: [48456.642447] [ 2006] 0 2006 2490 37 0 -17 -1000 dhclient
Jan 20 16:37:45 srv kernel: [48456.642450] [ 2070] 0 2070 29617 83 0 0 0 rsyslogd
Jan 20 16:37:45 srv kernel: [48456.642453] [ 2100] 0 2100 1029 1 0 0 0 acpid
Jan 20 16:37:45 srv kernel: [48456.642456] [ 2184] 0 2184 4168 0 0 0 0 atd
Jan 20 16:37:45 srv kernel: [48456.642459] [ 2736] 115 2736 18401 20 0 0 0 freshclam
Jan 20 16:37:45 srv kernel: [48456.642463] [ 2780] 0 2780 5086 29 0 0 0 cron
Jan 20 16:37:45 srv kernel: [48456.642466] [ 2811] 112 2811 7451 1 0 0 0 dbus-daemon
Jan 20 16:37:45 srv kernel: [48456.642469] [ 3508] 117 3508 9768 20 0 0 0 ntpd
Jan 20 16:37:45 srv kernel: [48456.642473] [ 3547] 109 3547 16584 1 0 0 0 /usr/sbin/postg
Jan 20 16:37:45 srv kernel: [48456.642476] [ 4619] 0 4619 12484 1 0 -17 -1000 sshd
Jan 20 16:37:45 srv kernel: [48456.642480] [ 4643] 0 4643 3689 2 0 0 0 getty
Jan 20 16:37:45 srv kernel: [48456.642484] [ 4644] 0 4644 3689 2 0 0 0 getty
Jan 20 16:37:45 srv kernel: [48456.642487] [ 4645] 0 4645 3689 2 0 0 0 getty
Jan 20 16:37:45 srv kernel: [48456.642490] [ 4646] 0 4646 3689 2 0 0 0 getty
Jan 20 16:37:45 srv kernel: [48456.642493] [ 4647] 0 4647 3689 2 0 0 0 getty
Jan 20 16:37:45 srv kernel: [48456.642496] [ 4648] 0 4648 3689 2 0 0 0 getty
Jan 20 16:37:45 srv kernel: [48456.642500] [17884] 0 17884 1019 5 0 0 0 imscp_daemon
Jan 20 16:37:45 srv kernel: [48456.642503] [17892] 0 17892 30362 32 0 0 0 proftpd
Jan 20 16:37:45 srv kernel: [48456.642506] [18639] 0 18639 10432 0 0 0 0 nginx
Jan 20 16:37:45 srv kernel: [48456.642509] [18642] 33 18642 10797 11 0 0 0 nginx
Jan 20 16:37:45 srv kernel: [48456.642512] [18654] 1001 18654 63626 1 0 0 0 php5-cgi
Jan 20 16:37:45 srv kernel: [48456.642516] [18677] 1001 18677 64573 453 0 0 0 php5-cgi
Jan 20 16:37:45 srv kernel: [48456.642520] [18678] 1001 18678 64886 782 0 0 0 php5-cgi
Jan 20 16:37:45 srv kernel: [48456.642523] [18679] 1001 18679 65022 340 0 0 0 php5-cgi
Jan 20 16:37:45 srv kernel: [48456.642527] [18680] 1001 18680 65305 351 0 0 0 php5-cgi
Jan 20 16:37:45 srv kernel: [48456.642530] [18681] 1001 18681 64888 648 0 0 0 php5-cgi
Jan 20 16:37:45 srv kernel: [48456.642533] [30698] 0 30698 1045 21 0 0 0 mysqld_safe
Jan 20 16:37:45 srv kernel: [48456.642548] [ 839] 0 839 68695 444 0 0 0 apache2
Jan 20 16:37:45 srv kernel: [48456.642551] [ 8136] 0 8136 14832 421 0 0 0 vlogger (access
Jan 20 16:37:45 srv kernel: [48456.642554] [ 8137] 33 8137 37334 171 0 0 0 apache2
Jan 20 16:37:45 srv kernel: [48456.642558] [ 5951] 0 5951 5454 81 0 0 0 dovecot
Jan 20 16:37:45 srv kernel: [48456.642562] [ 5964] 106 5964 3334 25 0 0 0 anvil
Jan 20 16:37:45 srv kernel: [48456.642566] [ 5965] 0 5965 3367 63 0 0 0 log
Jan 20 16:37:45 srv kernel: [48456.642570] [26994] 0 26994 9473 27 0 0 0 master
Jan 20 16:37:45 srv kernel: [48456.642573] [27000] 104 27000 10087 42 0 0 0 qmgr
Jan 20 16:37:45 srv kernel: [48456.642576] [27018] 104 27018 11049 36 0 0 0 tlsmgr
Jan 20 16:37:45 srv kernel: [48456.642579] [27757] 0 27757 62955 290 0 0 0 fail2ban-server
Jan 20 16:37:45 srv kernel: [48456.642583] [ 9016] 0 9016 5665 133 0 0 0 config
Jan 20 16:37:45 srv kernel: [48456.642586] [13948] 0 13948 17816 2 0 0 0 sshd
Jan 20 16:37:45 srv kernel: [48456.642589] [13974] 1000 13974 17816 64 0 0 0 sshd
Jan 20 16:37:45 srv kernel: [48456.642592] [13975] 1000 13975 5346 0 0 0 0 bash
Jan 20 16:37:45 srv kernel: [48456.642595] [14066] 1000 14066 9282 1 0 0 0 su
Jan 20 16:37:45 srv kernel: [48456.642598] [14081] 0 14081 4875 51 0 0 0 bash
Jan 20 16:37:45 srv kernel: [48456.642601] [17564] 104 17564 9991 22 0 0 0 pickup
Jan 20 16:37:45 srv kernel: [48456.642605] [18757] 0 18757 68709 406 0 0 0 apache2
Jan 20 16:37:45 srv kernel: [48456.642608] [20098] 0 20098 68709 406 0 0 0 apache2
Jan 20 16:37:45 srv kernel: [48456.642612] [20164] 0 20164 68709 407 0 0 0 apache2
Jan 20 16:37:45 srv kernel: [48456.642615] [20165] 0 20165 68709 418 0 0 0 apache2
Jan 20 16:37:45 srv kernel: [48456.642618] [20315] 0 20315 68709 406 0 0 0 apache2
Jan 20 16:37:45 srv kernel: [48456.642621] [20412] 0 20412 68709 406 0 0 0 apache2
Jan 20 16:37:45 srv kernel: [48456.642625] [20460] 0 20460 68709 406 0 0 0 apache2
Jan 20 16:37:45 srv kernel: [48456.642628] [20468] 0 20468 68709 408 0 0 0 apache2
Jan 20 16:37:45 srv kernel: [48456.642631] [20484] 0 20484 68709 417 0 0 0 apache2
Jan 20 16:37:45 srv kernel: [48456.642634] [20490] 0 20490 68709 406 0 0 0 apache2

Display More

Der Versuch, die Dinge mit einen ACPI Reboot über das vServerpanel zu richten schlug fehl. Erst ein Shutdown mit anschließendem Neustart brachte kurzzeitige Besserung. Beim Systemneustart viel mir auf, das er bis zum Start des i-MSCP Network Managers alles rasch ablief. Der Start dieses Network Managers dauerte schon recht lange. Danach zeigten sich dann Meldungen wie "too many connections", "out of memory" und "kill process". Mit letzterem wurden dann wichtige Prozesse beendet, wie z.B amavis, clamav, bis hin zu mysql. Dann stoppte der Startvorgang.
Handelt es sich dabei um eine Überlastung der MySQL Datenbank? Wodurch?

Curio

Curio · Jan 20th 2016

Nach Recherchen nun folgendes.
Es handelt sich hier wohl um das Out Of Memory Problem und durch die OOM-Killer Funktion des Systems werden dann die speicherhungrigsten Prozesse gekillt - bei mir halt bevorzugt MySQL. Damit sind natürlich Web- und Mailserver erledigt.
Heute lief das System bis 17.00 störungsfrei, dann plötzlich wieder OOM. Ich kann allerdings die Ursache nicht finden. Posten tue ich das Problem hier im Forum, da die i-MSCP-Updates die einzige Veränderung am System darstellen. Allerdings neben den automatischen Debian-Updates.

"top" zeigt z.B. folgendes Ergebnis:

Code

top - 17:29:09 up 14:19, 1 user, load average: 3,83, 18,49, 82,11Tasks: 143 total, 9 running, 134 sleeping, 0 stopped, 0 zombie%Cpu(s): 87,0 us, 12,6 sy, 0,0 ni, 0,0 id, 0,0 wa, 0,0 hi, 0,3 si, 0,0 stKiB Mem: 4061392 total, 760232 used, 3301160 free, 16196 buffersKiB Swap: 1951740 total, 138240 used, 1813500 free, 247112 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND29931 vu2014 20 0 297m 35m 4596 S 11,2 0,9 0:00.34 apache229932 vu2014 20 0 297m 35m 4596 S 11,2 0,9 0:00.34 apache229929 vu2014 20 0 297m 35m 4600 S 9,9 0,9 0:00.35 apache229933 vu2014 20 0 292m 31m 3844 R 9,2 0,8 0:00.28 apache229918 vu2014 20 0 298m 38m 6172 R 7,9 1,0 0:00.40 apache229922 vu2014 20 0 298m 38m 5920 R 7,9 1,0 0:00.38 apache229920 vu2014 20 0 297m 36m 4976 S 7,2 0,9 0:00.36 apache229934 vu2014 20 0 275m 14m 3396 R 3,0 0,4 0:00.09 apache229935 vu2014 20 0 273m 11m 3392 R 1,6 0,3 0:00.05 apache229936 vu2014 20 0 272m 10m 3392 R 1,0 0,3 0:00.03 apache229938 vu2014 20 0 271m 9644 3388 R 1,0 0,2 0:00.03 apache229937 vu2014 20 0 271m 9676 3388 R 0,7 0,2 0:00.02 apache227757 root 20 0 245m 2892 612 S 0,3 0,1 0:45.07 fail2ban-server29903 vu2014 20 0 298m 37m 5516 S 0,3 1,0 0:00.44 apache229930 root 20 0 23252 1716 1204 R 0,3 0,0 0:00.01 top 1 root 20 0 10648 20 0 S 0,0 0,0 0:01.75 init 2 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kthreadd 3 root 20 0 0 0 0 S 0,0 0,0 0:04.91 ksoftirqd/0 5 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kworker/u:0 6 root rt 0 0 0 0 S 0,0 0,0 0:00.00 migration/0 7 root rt 0 0 0 0 S 0,0 0,0 0:00.50 watchdog/0 8 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 cpuset 9 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 khelper 10 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kdevtmpfs 11 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 netns 12 root 20 0 0 0 0 S 0,0 0,0 0:00.16 sync_supers 13 root 20 0 0 0 0 S 0,0 0,0 0:00.00 bdi-default 14 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kintegrityd 15 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kblockd 17 root 20 0 0 0 0 S 0,0 0,0 0:00.05 khungtaskd 18 root 20 0 0 0 0 S 0,0 0,0 0:16.04 kswapd0 19 root 25 5 0 0 0 S 0,0 0,0 0:00.00 ksmd 20 root 39 19 0 0 0 S 0,0 0,0 0:00.00 khugepaged 21 root 20 0 0 0 0 S 0,0 0,0 0:00.00 fsnotify_mark 22 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 crypto 138 root 20 0 0 0 0 S 0,0 0,0 0:00.08 jbd2/vda6-8 139 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 ext4-dio-unwrit 148 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kworker/u:1 286 root 20 0 21248 4 4 S 0,0 0,0 0:00.05 udevd 399 root 20 0 21244 0 0 S 0,0 0,0 0:00.00 udevd 400 root 20 0 21244 0 0 S 0,0 0,0 0:00.00 udevd 411 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kpsmoused 415 root 20 0 0 0 0 S 0,0 0,0 0:00.00 khubd

Keine beunruhigenden Werte der einzelnen Prozesse. Allerdings stiegen die Apache2-Prozesse kurz darauf sprunghaft an und ebenso die Speicherauslastung.
Ich habe darauf hin den Apache2 gestoppt (/etc/init.d/apache2 stop). Die Werte normalisierten sich augenblicklich. Als ich dann aber den Apache2 wieder starten wollte, erhielt ich eine Fehlermeldung.

Code

[....] Starting web server: apache2(98)Address already in use: make_sock: could not bind to address 0.0.0.0:80no listening sockets available, shutting downUnable to open logsAction 'start' failed.The Apache error log may have more information. failed!

Im Apache2-Error-Log war dazu folgendes zu lesen:

Code

[Wed Jan 20 15:58:28 2016] [alert] i-MSCP Vlogger: Unable to dump tracker: DBI connect('database=imscp;host=127.0.0.1;port=3306','vlogger_user',...) failed: Can't connect to MySQL server on '127.0.0.1' (111) at /usr/local/sbin/vlogger line 493
[Wed Jan 20 16:13:14 2016] [alert] i-MSCP Vlogger: Unable to dump tracker: DBI connect('database=imscp;host=127.0.0.1;port=3306','vlogger_user',...) failed: Too many connections at /usr/local/sbin/vlogger line 493
[Wed Jan 20 16:32:25 2016] [notice] i-MSCP Vlogger: caught TERM, shutting down
zend_mm_heap corrupted
zend_mm_heap corrupted
[Wed Jan 20 17:32:30 2016] [notice] caught SIGTERM, shutting down

Ich verstehe nur soviel, dass es am Logging scheitert, da keine Datenbankverbindung hergestellt werden kann. Ich kann aber nicht erkennen worin die eigentliche Ursache liegt. Ist es Apache2, MySQL oder hat es etwas mit i-MSCP Konfigurationen zu tun.

Hat jemand von Euch vielleicht eine Idee. Würde mich über Anregungen freuen.

Gruß, Curio

mafioso · Jan 20th 2016

Hmm ich vermute weniger, dass imscp Amok läuft, ist mir noch kein Fall bekannt. Du könntest mal den SWAP hochschrauben, damit solltest du immerhin die Prozesskills abfangen können. Von welcher Version zu Welcher hast du eigt geupdated? Welche Plugins sind installiert und was für eine Hardware ist in Verwendung?

**bluecafe** · Jan 20th 2016

Also hinsichtlich der Fehlermeldung zend_mm_heap corrupted hilft vielleicht, den Wert für output_buffering in der php.ini zu erhöhen, s. auch diesen Link
http://stackoverflow.com/a/4453898

Curio · Jan 20th 2016

@'Ninos
Steht alles im ersten Post. Vielleicht noch erwähnenswert - der Apache läuft bei mir als mpm-itk.
Zur Server-Hardware: KVM-Rootserver Mv2 bei Netcup mit Intel Xeon E5-2620, 4 GB Arbeitsspeicher und 240 GB Festplatte.
Die Hardware ist für meine 10 Webseiten und entsprechende E-Mail Accounts mehr als ausreichend. Und es gab bis dato auch überhaupt keine Performance-Probleme.

An Updates habe ich jeweils von der unmittelbaren Vorgängerversion einmal auf die v1.2.10 und kurz darauf auf die v1.2.11 aktualisiert. Jeweils mit einer Woche Verzögerung zum Releasetermin.
Wie schon erwähnt, nutze ich keine Plugins. Kleine Änderungen nehme ich an der main.cf, master.conf oder der php.ini selbst vor, jedoch keine ausgefallenen Konfigurationen, die dieses Problem verursachen könnten.

@'bluecafe
Danke für den Tip. Habe mir das mal durchgelesen und Output_buffering von 4096 auf 8192 raufgesetzt, habe allerdings nicht viel Hoffnung, dass das was bringt.

Die Situation ist jetzt so, dass ich in "top" einen Haufen apache2 Prozesse angezeigt bekomme, und keine Ahnung habe, wieso. Kleiner Server, kaum Zugriffe auf die Webseiten. Eher schon Traffic über den Mailserver.

Code

top - 19:44:19 up 1:30, 1 user, load average: 232,43, 156,19, 70,87
Tasks: 621 total, 18 running, 603 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3,9 us, 4,3 sy, 0,0 ni, 0,0 id, 91,5 wa, 0,0 hi, 0,0 si, 0,4 st
KiB Mem: 4061664 total, 3976436 used, 85228 free, 460 buffers
KiB Swap: 1951740 total, 1951724 used, 16 free, 25552 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13243 vu2014 20 0 271m 10m 3280 R 1,0 0,3 0:00.05 apache2
12397 root 20 0 23608 1292 476 R 0,7 0,0 0:00.88 top
12420 vu2014 20 0 294m 16m 784 D 0,7 0,4 0:00.54 apache2
12597 vu2014 20 0 289m 19m 1328 D 0,7 0,5 0:00.44 apache2
12756 vu2014 20 0 288m 23m 1580 R 0,7 0,6 0:00.44 apache2
13166 vu2014 20 0 271m 9748 2080 R 0,7 0,2 0:00.14 apache2
13218 vu2014 20 0 271m 11m 3280 R 0,7 0,3 0:00.04 apache2
13248 vu2014 20 0 270m 8608 2444 D 0,7 0,2 0:00.02 apache2
6100 root 20 0 0 0 0 S 0,3 0,0 0:00.97 kworker/0:0
12424 vu2014 20 0 297m 20m 1324 D 0,3 0,5 0:00.57 apache2
12471 vu2014 20 0 293m 14m 456 D 0,3 0,4 0:00.50 apache2
12504 vu2014 20 0 293m 18m 896 D 0,3 0,5 0:00.52 apache2
12509 vu2014 20 0 294m 19m 868 D 0,3 0,5 0:00.56 apache2
12608 vu2014 20 0 294m 25m 928 D 0,3 0,6 0:00.57 apache2
12627 vu2014 20 0 294m 24m 868 D 0,3 0,6 0:00.53 apache2
12650 vu2014 20 0 293m 24m 1080 D 0,3 0,6 0:00.60 apache2
12653 vu2014 20 0 289m 22m 1688 D 0,3 0,6 0:00.44 apache2
12656 vu2014 20 0 294m 24m 904 D 0,3 0,6 0:00.56 apache2
12711 vu2014 20 0 297m 29m 1728 D 0,3 0,8 0:00.57 apache2
12728 vu2014 20 0 294m 26m 928 D 0,3 0,7 0:00.51 apache2
12776 vu2014 20 0 289m 25m 1748 D 0,3 0,6 0:00.49 apache2
12793 vu2014 20 0 285m 20m 960 D 0,3 0,5 0:00.45 apache2
12878 vu2014 20 0 294m 27m 888 D 0,3 0,7 0:00.54 apache2
13185 vu2014 20 0 271m 9240 2148 R 0,3 0,2 0:00.06 apache2
13192 vu2014 20 0 271m 9236 2084 D 0,3 0,2 0:00.05 apache2
13197 root 20 0 40368 2784 2084 D 0,3 0,1 0:00.03 trivial-rewrite
13212 vu2014 20 0 271m 10m 3280 R 0,3 0,3 0:00.03 apache2
13213 vu2014 20 0 272m 11m 3280 R 0,3 0,3 0:00.05 apache2
13216 vu2014 20 0 271m 10m 3280 R 0,3 0,3 0:00.03 apache2
13217 vu2014 20 0 271m 10m 3280 R 0,3 0,3 0:00.03 apache2
13237 vu2014 20 0 270m 9968 3188 R 0,3 0,2 0:00.04 apache2

Display More

**Nuxwin** · Jan 20th 2016

@Curio

First: You should use Apache2/PHP-FPM instead of Apache2 ITK which is a big memory consumer. For the rest, I can say nothing (your logs are not really relevant). You can always review default configuration for your service (MySQL, Apache ...). There is nothing changed in i-MSCP version 1.2.11 that can explain your problem. See the changelog.

You should also check configuration for PHP application of the domain(s) which belong to the vu2014 user. It seem that your server get abused.

I could have a look if you want. Just add my SSH key to your server.

Curio · Jan 20th 2016

@'Nuxwin

This is a great offer. Could I come back tomorrow on it? Have half an hour to work.

**Nuxwin** · Jan 20th 2016

Sure

Fiesling · Jan 21st 2016

Quote from Curio

Code

top - 19:44:19 up 1:30, 1 user, load average: 232,43, 156,19, 70,87

Tasks: 621 total, 18 running, 603 sleeping, 0 stopped, 0 zombie

%Cpu(s): 3,9 us, 4,3 sy, 0,0 ni, 0,0 id, 91,5 wa, 0,0 hi, 0,0 si, 0,4 st

KiB Mem: 4061664 total, 3976436 used, 85228 free, 460 buffers

KiB Swap: 1951740 total, 1951724 used, 16 free, 25552 cached

I was stimmt da nicht
Du hast dort eine Load von 232 ?!?
Also Server gerade sehr überlastet. Auch reichlich Prozesse am laufen..

Bei mir sind 21 Seiten am laufen - 4 Streamserver - red5-mediaserver und 3 gameserver und ich komm auf ca. 350 Prozesse insgesammt.
Unter was für ein CMS läuft die HP?

Curio · Jan 21st 2016

Halleluja, alles wieder in bester Ordnung.

Nach dem ich das Problem mit den zahlreichen Prozessen nicht eingrenzen konnte und auch das Einspielen von Backups nur kurzzeitige Besserung brachte, hat mein Serverprovider Netcup sich erweichen lassen meinem KVM auf einen anderen Node zu setzen. Und siehe da, alles wieder in Ordnung.
2 Nächte ohne Schlaf und Adrenalin pur.

Nun stellt sich das Thema also doch eindeutig als nicht zu i-MSCP gehörig heraus. Ich bedanke mich unbedingt noch mal für die Hilfsbereitschaft hier. Ist viel wert, wenn man einfach gerade nicht weiß, worin das Problem liegt und viel dran hängt.

@Nuxwin

Thank you very much for your great helpfulness. But the problem could be solved. The serverprovider Netcup sat my KVM-Server on different node and that was it. Apparently a technical problem of the server provider.
Now I'm happy and I am looking forward to the new Version of i-MSCP.

KVM Server nach Update auf i-MSCP v1.2.11 extrem verlangsamt

Share

Daily visitors