Alle 15 Minunten alles langsam / down aus unerklärlichen Gründen

[Skorpurion]

Hallo,
ich habe einen VPS Linux XXL bei HE.

Seit einiger Zeit habe ich mit dem Probleme.
Und zwar sind etwa alle 15 Miunten alle Dienste ( SSH, Apache, FTP ) total langsam.
Das dauerd bis zu zwei Minunten, dann geht wieder alles normal und schnell.
In der Zeit schaltet der Server aber nicht ganz ab, da SSH eingeloggt ist, aber eben lahmt.

Der Server benutzt Debian 3.1 mit PHP 5 ( Suhosin Patch ), Apache 2.0 und mySQL 5 mit VHCS Omega RC1.

Ich habe HE natürlich schon mehrere Tage befragt, keine Lösung.
Auch im dortigen Forum konnte nicht geholfen werden.

Ich für meinen Teil meine, dass das am Wirtssystem liegt, da es urplötzlich kam.
Da war dann alles langsam.
Das war ein Tag nachdem der Server neuaufgesetzt wurde. Aber an dem Tag, als es begann, habe ich nichts gemacht.
Und es ist auch nichts anders gemacht worden oder so. Sonst ist der Server ja auch schnell.

Sonstiges zum Server:
top "normal":

top - 16:56:28 up 6 days,  4:17,  1 user,  load average: 0.11, 3.06, 4.31
Tasks:  99 total,   1 running,  98 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.8% us,  0.4% sy,  0.0% ni, 93.3% id,  4.5% wa,  0.0% hi,  0.0% si
Mem:   6215720k total,  5637784k used,   577936k free,   371992k buffers
Swap: 12289716k total,    18168k used, 12271548k free,  1195492k cached

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
16226 www-data  16   0 23580 9308 4512 S  9.8  0.1   0:01.42 apache2
15493 mysql     16   0  215m  72m 5320 S  2.0  1.2  84:27.63 mysqld
18051 root      15   0  2060  964  744 R  2.0  0.0   0:00.01 top
    1 root      16   0  1504  512  452 S  0.0  0.0   0:00.04 init
15411 root      16   0  1780  604  516 S  0.0  0.0   0:02.07 syslogd
15455 root      16   0  2512 1240 1020 S  0.0  0.0   0:00.00 mysqld_safe
15494 root      15   0  1488  500  440 S  0.0  0.0   0:00.00 logger
15570 root      20   0 24480  21m 2124 S  0.0  0.4   0:00.48 spamd
15603 root      16   0 24480  20m  600 S  0.0  0.3   0:00.00 spamd
15604 root      16   0 24480  20m  500 S  0.0  0.3   0:00.00 spamd
15605 root      16   0 24480  20m  500 S  0.0  0.3   0:00.00 spamd
15606 root      21   0 24480  20m  500 S  0.0  0.3   0:00.00 spamd
15607 root      20   0 24480  20m  500 S  0.0  0.3   0:00.00 spamd
15741 root      16   0  3472 1028  784 S  0.0  0.0   0:08.06 sshd
15754 nobody    15   0  4592 1292  604 S  0.0  0.0   0:00.56 proftpd
15757 root      16   0  1764  744  604 S  0.0  0.0   0:00.15 cron
15766 root      16   0  1492  384  324 S  0.0  0.0   0:00.00 vhcs2_daemon

Und in den 15 Min. Bereich:

top - 17:00:43 up 6 days,  4:21,  1 user,  load average: 1.06, 1.59, 3.37
Tasks:  96 total,   1 running,  95 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.2% us,  0.1% sy,  0.0% ni, 26.3% id, 73.4% wa,  0.0% hi,  0.0% si
Mem:   6215720k total,  6200360k used,    15360k free,   376024k buffers
Swap: 12289716k total,    18168k used, 12271548k free,  1556240k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
16300 www-data  15   0 23492 9420 4712 S  0.3  0.2   0:02.03 apache2
18051 root      15   0  2064 1068  832 R  0.3  0.0   0:00.80 top
    1 root      16   0  1504  512  452 S  0.0  0.0   0:00.04 init
15411 root      15   0  1780  604  516 S  0.0  0.0   0:02.07 syslogd
15455 root      16   0  2512 1240 1020 S  0.0  0.0   0:00.00 mysqld_safe
15493 mysql     15   0  215m  72m 5320 S  0.0  1.2  84:29.73 mysqld
15494 root      15   0  1488  500  440 S  0.0  0.0   0:00.00 logger
15570 root      20   0 24480  21m 2124 S  0.0  0.4   0:00.48 spamd
15603 root      16   0 24480  20m  600 S  0.0  0.3   0:00.00 spamd
15604 root      16   0 24480  20m  500 S  0.0  0.3   0:00.00 spamd
15605 root      16   0 24480  20m  500 S  0.0  0.3   0:00.00 spamd
15606 root      21   0 24480  20m  500 S  0.0  0.3   0:00.00 spamd
15607 root      20   0 24480  20m  500 S  0.0  0.3   0:00.00 spamd
15741 root      16   0  3472 1028  784 S  0.0  0.0   0:08.06 sshd
15754 nobody    15   0  4592 1292  604 S  0.0  0.0   0:00.56 proftpd
15757 root      15   0  1764  744  604 S  0.0  0.0   0:00.15 cron
15766 root      16   0  1492  384  324 S  0.0  0.0   0:00.00 vhcs2_daemon

Crons:

#mySQL Backups START
00      */6    * * *  /....sh
00      */6    * * *  /....sh
00      */6    * * *  /....sh
#mySQL Backups ENDE
00      23     * * *  rm -r /tmp/*
# delayed tasks START.

0       23      * * *  /var/www/vhcs2/engine/quota/vhcs2-dsk-quota &>/var/log/vhcs2/vhcs2-qsk-quota.log

0,30    *       * * *  /var/www/vhcs2/engine/traffic/vhcs2-srv-traff &>/var/log/vhcs2/vhcs2-srv-traff.log
30      23      * * *  /var/www/vhcs2/engine/tools/vhcs2-httpd-logs-mngr &>/var/log/vhcs2/vhcs2-httpd-logs-mngr.log

0,30    *       * * *  /var/www/vhcs2/engine/traffic/vhcs2-vrl-traff &>/var/log/vhcs2/vhcs2-vrl-traff.log

0       1       * * *  /var/www/vhcs2/engine/backup/vhcs2-backup-all yes &>/var/log/vhcs2/vhcs2-backup-all-mngr.log

# [{DMN_NAME}] backup task START.
# [{DMN_NAME}] backup task END.

# delayed tasks END.

( Die ersten drei sind Sachen vom mySQL Backup Script, das kann es aber nicht sein, da es eben nur alle 6 Stunden aufgerufen wird, und das ging früher auch. Ich schließe Crons eh aus, aber wer weiß, ne ? )

mySQL Server:

Dieser MySQL-Server läuft bereits 6 Tage, 8 Stunden, 24 Minuten und 4 Sekunden. Er wurde am 10. Mai 2007 um 12:38 gestartet.

Traffic 	ø pro Stunde
Empfangen	1 GB	7 MB
Gesendet	487 MB	3 MB
Insgesamt	1 GB	10 MB
Verbindungen	ø pro Stunde	%
max. gleichzeitige Verbindungen	30  	--- 	--- 
Fehlgeschlagen	7  	0,05  	0,01%
Abgebrochen	2  	0,01  	0,00%
Insgesamt	133 k	874,42  	100,00%

Insgesamt	ø pro Stunde	ø pro Minute	ø pro Sekunde
9 M	60,35 k	1,01 k	16,76

Außer zwei Foren und einem Blog ( Skorpurion www.rechner-support.com Die Purzelzwerge | Startseite ) läuft noch ein jabberd-Server ( der aus den Sarge Quellen ). Da sind aber nur ne handvoll User drauf, und auch wenn der aus ist, kommt es zu dem Problem.

Die Apache Error Log zeigt keine Probleme. Früher mal, dass nicht genügend Ram frei wäre, das ist aber nun nicht mehr. Weitere Errors sind nicht da, es lahmt halt einfach.

So, falls noch Infos gebraucht werden, einfach melden .

Dann hoffe ich mal, dass das gelöst wird.

Aso, habe das auch schon in einem anderen Forum gepostet, nur gab es da auch noch keine wirkliche Lösung:
yourWBB | Server-Place | [Problem mit Server] Alle ~ 15 Minunten totaler Einbruch des Servers

Gruß

 

[Skorpurion]

Wie oben erwähnt :

Und zwar sind etwa alle 15 Miunten alle Dienste ( SSH, Apache, FTP ) total langsam.

Es ist also wirklich im 15 Minunten Takt.

Übrigens, laut meinem Parnter, war z. B. heute früh alles über längere Zeit dicht. Und auch das Wirtssystem ( wo VZPP läuft, deswegen kann ich das wissen ) war sehr lahm / nicht erreichbar.

Ich glaube, dass das an meinem Hoster liegt, der stellt sich aber quer:
kann nicht sein, ist nicht so, Infos zum Verbrauch gibt es nicht, passt alles.

Und der Support wollte mir eine Optimierung aufs Auge drücken, was mich 25 Euro / 15 Minunten oder so gekostet hätte, ohne Erfolgsgarantie.

Aber das kann es nicht sein, zumal manchmal kaum User on sind und trotzdem das.

Gäbe es ansonsten noch Lösungsvorschläge ? Könnte ja trotzdem was anders sein, wer weiß ?

Kann man eigentlich den Vertrag bei Verdacht von Nicht Erfüllung der vertraglich garantierten Leistung kündigen ?
Mal davon abgesehen, dass u. A. eine bestimmte Userzahl zugesichert wurde, welche auf dem Server gleichzeitig on sein kann, was aber später vom Support, nachdem der Server bestellt war, wiederlegt wurde ...

 

[Messiah]

Hi,

Übrigens, laut meinem Parnter, war z. B. heute früh alles über längere Zeit dicht. Und auch das Wirtssystem ( wo VZPP läuft, deswegen kann ich das wissen ) war sehr lahm / nicht erreichbar.

Hast Du das schon dem Support so mitgeteilt?

Ich glaube, dass das an meinem Hoster liegt, der stellt sich aber quer:
kann nicht sein, ist nicht so, Infos zum Verbrauch gibt es nicht, passt alles.

Seltsam...

Und der Support wollte mir eine Optimierung aufs Auge drücken, was mich 25 Euro / 15 Minunten oder so gekostet hätte, ohne Erfolgsgarantie.

Ernsthaft? Ich kenn das nur so, dass der Support ein Auge auf den Server wirft ob sie was finden können, dafür Geld zu verlangen find ich seltsam. Wo steht der Server?

Gäbe es ansonsten noch Lösungsvorschläge ? Könnte ja trotzdem was anders sein, wer weiß ?

Installier Dir 'vmstat'
Lass vmstat laufen mit

nohup vmstat > /var/log/vmstat.log &

und mach Dir einen cronjob, der minütlich die wichtigsten Eckdaten mitlogt. Damit gehst Du dann zum Support, falls das darauf hindeutet, dass es nicht an Deiner VPS liegt. Wenn sie dann immer noch blocken, würde es mich wundern.

Kann man eigentlich den Vertrag bei Verdacht von Nicht Erfüllung der vertraglich garantierten Leistung kündigen ?

Kann man sicher, nur was genau wurde vertraglich definiert. Ich bin juristischer Laie, aber ich glaube nicht, dass Du da vor der Zeit raus kommst, es sei denn Dein Hoster ist von der angenehmen Sorte, was ich oben nicht gerade aus dem Text raus lesen kann.

Mal davon abgesehen, dass u. A. eine bestimmte Userzahl zugesichert wurde, welche auf dem Server gleichzeitig on sein kann, was aber später vom Support, nachdem der Server bestellt war, wiederlegt wurde ...

Das wäre meine erste verbindliche Frage vor Vertragsabschluß, wenn ich irgendwas auf Hosts mit 'flex' ram mieten würde. Ich steh mehr auf 'der Ram ist fest vorgegeben', weniger aber dafür konstant davon - und die Gewissheit, dass da nicht auf einmal 500 Leute auf einem Server hocken. Da ist Webhosting ja noch schneller.

Greetz,
Ralf

 

[Skorpurion]

Hast Du das schon dem Support so mitgeteilt?

Nachdem ich sagte, dass das nicht an mir liegen kann, und die doch mal schauen sollen, ob mir nicht Leistung geklappt wird, meinten die, würde alles passen ...

Ernsthaft? Ich kenn das nur so, dass der Support ein Auge auf den Server wirft ob sie was finden können, dafür Geld zu verlangen find ich seltsam. Wo steht der Server?

Nachschauen schon, die wollen aber den Apache und so "optimieren".

Installier Dir 'vmstat'
Lass vmstat laufen mit

nohup vmstat > /var/log/vmstat.log &

und mach Dir einen cronjob, der minütlich die wichtigsten Eckdaten mitlogt. Damit gehst Du dann zum Support, falls das darauf hindeutet, dass es nicht an Deiner VPS liegt. Wenn sie dann immer noch blocken, würde es mich wundern.

Wie kann ich denn die Werte auswerten ? Also ich meine, woran erkenne ich, dass das nicht an mir liegt ?

Das wäre meine erste verbindliche Frage vor Vertragsabschluß, wenn ich irgendwas auf Hosts mit 'flex' ram mieten würde. Ich steh mehr auf 'der Ram ist fest vorgegeben', weniger aber dafür konstant davon - und die Gewissheit, dass da nicht auf einmal 500 Leute auf einem Server hocken. Da ist Webhosting ja noch schneller.

Ich habe 1024 MB Ram garantiert ( darf auch geswapped sein laut Vertrag ) und rund 1, 5 GB ( habe die genaue Zahl nicht im Kopf ) dynamisch.

Hoster ist im übriegen HE und der Server ist der VPS Linux XXL.

Gruß

 

[Messiah]

Hi,

Nachschauen schon, die wollen aber den Apache und so "optimieren".

Wenn Du nicht gerade eine Seite mit hohen Besucherraten da drauf laufen hast, sollte da wenig bis gar nichts zu optimieren sein. Der Speicher ist mehr als üppig?!

Wie kann ich denn die Werte auswerten ? Also ich meine, woran erkenne ich, dass das nicht an mir liegt ?

Mit 'man vmstat' gibts dazu genaue Infos, wichtig sind vor allem:

vmstat -n 1
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 1  0     28   4616   5320  62396    0    0     2     5   15    13  1  0 99  0
 1  0     28   4556   5320  62396    0    0     0     0  110    17  0  0 100  0
 1  0     28   4196   5320  62400    0    0     0     4  137    35 16  0 84  0

si/so = Swap Aktivitäten out/in
bi/bo = HDD aktivitäten out/in
in = Interrupts
cs = Context Switches
id = Prozent CPU Idle
wa = Prozesse wartend

Du kannst da recht schön sehen, wieviel der Server arbeitet. Sind die cs spontan sehr hoch, ists meist irgendwas in der Datenbank. Geht die CPU spontan sehr hoch ists zumeist der Viren- oder Spamfilter. Geht die bi/bo hoch wird viel auf der Platte gearbeitet, das sind meist Cronjobs wie logrotate etc. Geht die si/so hoch ist der Speicher erledigt.

Die endgültige Interpretation ist recht komplex, paste doch einfach ein paar Zeilen hier rein wenn Dir was auffällt.

Hast Du mal spaßeshalber einen Last-Test gemacht? Platte voll geschrieben mit dd, linux compiled, unixbench laufen lassen, was in der Art?

Greetz,
Ralf

PS: Für 30 Euro und mit DEM Ram sollte da _viel_ drauf laufen und auch reichlich Raum für 'nicht optimierte Apaches' sein. Das wundert mich sehr.

 

[Skorpurion]

Hallo,
der Apache ist sogar "leicht" optimiert. Also ein paar Einstellungen habe ich nach einer Anleitung optimiert.
Und auch in der php.ini die HostName Lookups auf Off und so.

Hier mal die Logs auf der vmstat:

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 2  0  18544 287328 408396 1221372    0    0     0     0    0     4  2  0 93  5
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 4  0  18544  16896 401668 1376616    0    0     0     0    0     4  2  0 93  5
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 0  0  18544 168680 402588 1257136    0    0     0     0    0     4  2  0 93  5
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 0  0  18544 361304 404908 1150816    0    0     0     0    0     5  2  0 93  5

Die ersten sind um 21 Uhr, also im 15 Minunten Takt.
Danach also dann 21:03 etc.

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 0  0  17808 636048 344280 1218060    0    0     0     0    0     8  2  0 93  5
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 0  0  17808 626616 344840 1220100    0    0     0     0    0     8  2  0 93  5
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 2  0  17808 598944 345244 1221776    0    0     0     0    0     8  2  0 93  5
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 3  4  17816  16760 341852 1572000    0    0     0     0    0     8  2  0 93  5
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 6  0  17824  47288 344200 1600584    0    0     0     0    0     8  2  0 93  5

Das letzte hier ist 14:03.

Hier mal die ganze:
http://www.skorpurion.de/vmstat.log
Also der erste Punkt ist wie gesagt 21 Uhr ( gestern ) und dann im Minuntentakt.

Ach, und Tests habe ich nicht weiter laufen lassen. Habe aber mal mit ab getestet:

ab -n 500 http://www.rechner-support.com/index.php
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.141 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking www.rechner-support.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Finished 500 requests


Server Software:        Apache/2.0.54
Server Hostname:        www.rechner-support.com
Server Port:            80

Document Path:          /index.php
Document Length:        105631 bytes

Concurrency Level:      1
Time taken for tests:   210.549797 seconds
Complete requests:      500
Failed requests:        497
   (Connect: 0, Length: 497, Exceptions: 0)
Write errors:           0
Total transferred:      52957592 bytes
HTML transferred:       52787092 bytes
Requests per second:    2.37 [#/sec] (mean)
Time per request:       421.100 [ms] (mean)
Time per request:       421.100 [ms] (mean, across all concurrent requests)
Transfer rate:          245.62 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:   364  420  57.1    395     736
Waiting:      351  406  55.6    382     718
Total:        364  420  57.1    395     736

Percentage of the requests served within a certain time (ms)
  50%    395
  66%    423
  75%    448
  80%    461
  90%    500
  95%    537
  98%    584
  99%    608
 100%    736 (longest request)

ab -n 500 -c 200 http://www.skorpurion.de/index.php
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.141 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking www.skorpurion.de (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Finished 500 requests


Server Software:        Apache/2.0.54
Server Hostname:        www.skorpurion.de
Server Port:            80

Document Path:          /index.php
Document Length:        1229 bytes

Concurrency Level:      200
Time taken for tests:   79.813249 seconds
Complete requests:      500
Failed requests:        4
   (Connect: 0, Length: 4, Exceptions: 0)
Write errors:           0
Total transferred:      893715 bytes
HTML transferred:       757155 bytes
Requests per second:    6.26 [#/sec] (mean)
Time per request:       31925.299 [ms] (mean)
Time per request:       159.626 [ms] (mean, across all concurrent requests)
Transfer rate:          10.93 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  309 572.5     91    3001
Processing:   201 16054 28457.0   1510   79406
Waiting:      142 8964 17013.0   1223   79369
Total:        430 16363 28565.3   1733   79434

Percentage of the requests served within a certain time (ms)
  50%   1733
  66%   2175
  75%   2360
  80%  70261
  90%  72072
  95%  72194
  98%  72199
  99%  72202
 100%  79434 (longest request)

In die 15 Min reingefallen.

 

[Messiah]

Hi,

ich kenne das Hostsystem nicht, aber ich kann da beim besten Willen keine erhöhte Last von Deiner Seite aus erkennen. Das vmstat zeigt eigentlich nur, dass von Dir Prozesse auf die Verfügbarkeit von CPU Leistung warten. Aus meiner Sicht ist der Host einfach alle 15 Minuten schwer beschäftigt.

Wie gesagt: Ich kenn den Host nicht und ich kann mich täuschen, aber wirklich auffälliges von Deinem Server aus würde ich da nicht 'raus interpretieren.

Zum Apache: Wenn da der Hostlookup auf 'aus' steht und das sowieso ein Apache2 ist (kein keepalive Problem) dann sollte der auch keinerlei Probleme machen...

Greetz,
Ralf

 

[Skorpurion]

Zumal ich ehrlich gesagt auch nicht wüsste, was bei mir alle 15 Minunten dafür sorgt, dass neben dem Apache auch SSH und der FTP lahmen.
Und wenn es der Apache wäre oder so, wäre es ja wohl öfter, oder ?

Na, ich werde das mal an HE schicken.

Werde dann auch mal bescheid geben, was die dazu sagen.

 

[Eboreus]

Ich habe das gleiche VPS-System von HE und habe seit einigen Tagen ein ähnliches Problem, allerdings alle 30 Minuten (immer kurz nach voll und kurz nach halb).

Skorpurion falls du das hier noch lesen solltest, wäre es klasse, wenn du deine Erfahrungen noch mal mitteilst.

Wenn es sonst zu dem Thema neue Erkenntnisse gibt, freue ich mich über Hinweise.

 

[Skorpurion]

Hallo,
wie gut, dass ich damals die E-Mail-Aktivierung an hatte .

Okay, also das Ende vom Lied war, dass der Serverbesitzer ( kümmere mich ja nur um den ) dort angerufen hat. E-Mails wurden von HE dann meist mit genau dem Gegenteil beantwortet. Sehr komsich und verwirrend irgendwie, da man ja nicht wusste, was stimmt jetzt. Jedenfalls nach mehrmaligen Telefonaten und einigem hin und her ging dann wie durch Zauberhand alles wieder. Hat wohl HE was dran gemacht.
Also ich würde dort anrufen, und mich beschweren.
Vorausgesetzt Du hast schon alle möglichen Fehler ausgeschlossen !

Ansonsten, kann ich Dir da nur Glück wünschen .

 

[haraldms]

crontab

# delayed tasks START.

10 23 * * * /var/www/vhcs2/engine/quota/vhcs2-dsk-quota &>/var/log/vhcs2/vhcs2-qsk-quota.log

0,30 * * * * /var/www/vhcs2/engine/traffic/vhcs2-srv-traff &>/var/log/vhcs2/vhcs2-srv-traff.log
35 23 * * * /var/www/vhcs2/engine/tools/vhcs2-httpd-logs-mngr &>/var/log/vhcs2/vhcs2-httpd-logs-mngr.log

3 */2 * * * /var/www/vhcs2/engine/traffic/vhcs2-vrl-traff &>/var/log/vhcs2/vhcs2-vrl-traff.log

10 1 * * * /var/www/vhcs2/engine/tools/vhcs2-backup-all yes &>/var/log/vhcs2/vhcs2-backup-all-mngr.log

# [{DMN_NAME}] backup task START.

Bei einem unserer Server mit VHCS2 trat das Ausbremsen katastrofal auf.
Im "top" war es der Job: /var/www/vhcs2/engine/traffic/vhcs2-vrl-traff
der sogar mehrmals gleichzeitig auftauchte.
Ganz einfach: Der letzte Lauf von "vhcs2-vrl-traff" war noch nicht fertig, da lief 30 min später der nächste auf.
"cronjobs" sollten immer eine Sperre, "run lock", haben, so dass sie nicht mehrmals nacheinander auf laufen.
Nun, wenn der erste Lauf nicht fertig ist und der zweite seine Daten darüber schreibt, dann laufen beide sehr sehr lange und werden nicht fertig.
94% iowait = Warten auf Diskaktivität.
Ich habe, siehe oben, die Aufrufzeit in der crontab von alle 30 Min. auf alle 2h gesetzt. Technisch besser wäre aber ein Sperre gegen zweites Starten, wenn der erste Lauf nicht fertig ist: Tipp an die VHCs2-Entwickler.