Problème serveur dédié surchargé entre 3h et 4h du matin

[sietjp]

Bonjour,
J'ai problème vraiment trés étrange sur mon serveur dédié. Merci pour ceux qui auront le courage de lire jusqu'au bout car je ne sais pas comment m'en sortir.

Un samedi matin vers 10 heures d'il y a 3 semaines, je teste mon serveur et surprise ça ne répond pas. Je me connecte sur le serveur et je constate que le processeur est à 100%, ça swappe à fond, et apache est dans le choux. Je relance plusieurs fois apache et à chaque fois au bout de quelques minutes la machine s'emballe de nouveau.

Au bout d'un moment le serveur ne répond plus et j'appelle la hotline et on me dit que le disque dur vient de lâhcer. J'attend le changement du disque et je passe mon dimanche à tout réinstaller.

Je pensais que le priblème venait donc d'nue faiblesse du disque mais je me trompais. Lundi matin, le serveur est de nouveau down. Je le realnce et la journée se passe correctement. Je met au point un petit script en tâche de fond qui relance apache quand le nombre de proces est anormalement grand et qui trace tout ça dans un log.

Au bout de quelques jour je constate que TOUTES LES NUITS entre 3H et 4H du mat le serveur est surchargé alors que le traffic est au minimum. J'ai aussi logué les slow-queries de mysql et je constate des temps de requêtes allucinant (plusieurs 10aines de secondes) entre 3h et 4h du matin, tous les jours.

Alors voilà, je sais pas trop quoi faire, surtout qu'entre 4h et 5h du mat je suis au lit en général. J'aimerais savoir si ça évoque quelque chose à certains d'entre vous. Pensez vous que ce soit une attaque délibéré, ça ressemble plutôt à un virus ou à une attaque d'un ordinateur infecté?

[ApocalXNow]

T'as pas une tache cron qui s'execute à cette heure la? (genre calcul de stats par exemple)

[leffred]

tu dois avoir un batch qui tourne a cette heure ...

Peut etre un awstats qui genere les stats du serveur ou autre chose.

si tu es debout a l'heure de la surcharge, essaye de voir quel process prend l'occupation proc.

[maddanny]

Vu l'heure que tu indiques, tu devrais regarder du coté des crons.
Est ce que tu as vu ce qui prennait 100% du cpu ? Fais un top et classe par cpu

MADdanny

PS: désolé j'avais pas vu les autres réponses avant de poster

[sietjp]

Merci de ces réponses trés rapides.

Malheureusement je n'ai pas eu la présence d'esprit de regarder ce qui prenait les 100% du cpu le jour où j'ai eu le problème à 10 heures du matin. J'étais persuadé que c'était apache qui s'était emmêlé les pinceaux alors qu'en fait la multiplication des process d'apache n'était pas la cause mais la conséquence d'un autre problème plus sournois.

J'ai pas de awstats et au niveau des cron j'ai rien touché pour la bonne raison que je ne sais pas encore comment ça marche. Ceux sont les crons d'origine du serveur, j'ai regardé un peu justement ce matin et il n'y a rien qui est appelé à ces heures là.

Mais ce qui m'étonne vraiment c'est la ponctualité du problème, que j'ai pu constaté sur le log mysql slow-queries.log, ça commence à 3 heures pile, le serveur turbine pendant 1 heure et ça se termine à 4heures pile c'est vraiment incroyable.

Sinon j'ai lancé des traces pour cette nuit. Quand le serveur est surchargé je logue un "netstat" et un "ps aux" j'espère avoir plus d'élément demain.

[leffred]

bon, si tu es sur de pas avoir d'awstats...

peut etre un autre soft de stats ou generation/deplacement de logs. ou tout simplement compression de données en gzip.

Ikl y a pas mal de possibilité mais le fait que l'heure soit fixe évoque clairement qu'il s'agit d'un batch qui se lance sur ton serveur.

[Akh]

bon, si tu es sur de pas avoir d'awstats...

peut etre un autre soft de stats ou generation/deplacement de logs. ou tout simplement compression de données en gzip.

Ikl y a pas mal de possibilité mais le fait que l'heure soit fixe évoque clairement qu'il s'agit d'un batch qui se lance sur ton serveur.

Bonjour

j'ai eu le même problème il y a quelques semaines à 3h du matin. ça venait justement de awastats et mes back up de base de données.

Le problème s'est repété une dizaine de fois

[henri10]

Lance un top au moment du souci pour voir ce qui prose probleme, et regarde si tu n'as pas de cron de programmé pour cette heure là.

A titre préventif, un excellent utilitaire pour killer automatiquement les process qui utilisent trop de ressources, et donc éviter les problèmes : -http://webhosting-tools.com/view.cgi/WatchDog

[thierry8]

Très probablement ta sauvegarde de données qui se lance à 3h du mat', heure à laquel le trafic est quasi nul...

Mais de toute manière après ce petit passage tout est normal ?
(si c'est le cas, rien d'alarmant)

note: demande à ton fournisseur, il pourra te répondre rapidement.

[sietjp]

Très probablement ta sauvegarde de données qui se lance à 3h du mat', heure à laquel le trafic est quasi nul...

Mais de toute manière après ce petit passage tout est normal ?
(si c'est le cas, rien d'alarmant)

note: demande à ton fournisseur, il pourra te répondre rapidement.

En fait tout n'est pas normal après le le pic de process. Si je n'avais pas fait ce petit script en perl qui détecte qu'apache est dans le rouge et qui fait un restart, apache part en vrille et le site web est down.
Sinon je n'ai pas encore installer de sauvegarde de données.

[sietjp]

Voici les logs les plus importants de cette nuits, je remarque quelques threads inhabituels (je n'ai mis que les threads qui me semblent improtant pour l'analyse du problème) :

Code: Tout sélectionner

root     25031  0.0  0.4  7628  880 ?        Ss   Jan31   0:08 sendmail: rejecting connections on daemon MTA: load average: 18
root     14868  0.0  4.1 38180 7920 ?        Ss   Feb20   0:00 /usr/sbin/httpd
root     32074  0.0  1.6  8904 3104 ?        R    Feb20   0:00 perl checkapache.pl
apache   21727  0.1 13.3 39344 25452 ?       S    Feb20   1:20 /usr/sbin/httpd
apache   21757  0.2 13.1 39220 25120 ?       S    Feb20   1:24 /usr/sbin/httpd
apache   21758  0.2 13.3 39264 25392 ?       S    Feb20   1:36 /usr/sbin/httpd
apache   23203  0.2 13.3 39548 25548 ?       S    Feb20   1:26 /usr/sbin/httpd
apache   23256  0.1 13.2 39348 25200 ?       S    Feb20   1:20 /usr/sbin/httpd
apache   23257  0.2 13.2 39264 25292 ?       S    Feb20   1:25 /usr/sbin/httpd
apache   23307  0.2 13.2 39292 25288 ?       S    Feb20   1:33 /usr/sbin/httpd
apache   23309  0.1 13.1 39252 25120 ?       S    Feb20   1:18 /usr/sbin/httpd
apache   23310  0.1 13.2 39244 25316 ?       S    Feb20   1:19 /usr/sbin/httpd
apache   23361  0.1 13.2 39280 25248 ?       S    Feb20   1:20 /usr/sbin/httpd
apache   23363  0.2 13.6 39916 25948 ?       S    Feb20   1:27 /usr/sbin/httpd
apache   23368  0.2 13.2 39304 25204 ?       S    Feb20   1:26 /usr/sbin/httpd
apache   25621  0.1 13.4 39724 25744 ?       S    Feb20   1:08 /usr/sbin/httpd
apache   13780  0.2 13.2 39256 25208 ?       S    Feb20   1:04 /usr/sbin/httpd
apache   20389  0.1 13.0 39296 24952 ?       S    Feb20   0:54 /usr/sbin/httpd
apache    2097  0.1 13.2 39292 25180 ?       S    Feb20   0:52 /usr/sbin/httpd
apache    2118  0.1 13.0 39284 24836 ?       S    Feb20   0:52 /usr/sbin/httpd
apache    2119  0.1 13.3 39664 25444 ?       S    Feb20   0:45 /usr/sbin/httpd
apache   16846  0.1 13.1 39304 25112 ?       S    Feb20   0:45 /usr/sbin/httpd
root     15657  0.0  0.4  5956  876 ?        S    04:02   0:00 crond
root     15658  0.0  0.4  2312  908 ?        Ss   04:02   0:00 /bin/bash /usr/bin/run-parts /etc/cron.daily
root     15661  0.0  1.4  5816 2676 ?        S    04:02   0:00 /usr/bin/perl -w /etc/cron.daily/00-logwatch
root     15662  0.0  0.2  2060  552 ?        S    04:02   0:00 awk -v progname=/etc/cron.daily/00-logwatch progname {?????   print progname ":\n"?????   progname="";????       }????       { print; }
apache   16169  0.0  6.1 39108 11664 ?       S    04:03   0:00 /usr/sbin/httpd
apache   16171  0.0  7.0 39272 13516 ?       S    04:03   0:00 /usr/sbin/httpd
apache   16172  0.0  6.7 39172 12884 ?       S    04:03   0:00 /usr/sbin/httpd
apache   16189  0.0  5.7 39100 10932 ?       S    04:03   0:00 /usr/sbin/httpd
apache   16970  0.0  6.1 39092 11748 ?       S    04:07   0:00 /usr/sbin/httpd
apache   17009  0.0  5.7 39100 10936 ?       S    04:07   0:00 /usr/sbin/httpd
root     17207  0.0  0.5  4504 1000 ?        S    04:08   0:00 sh -c ( /bin/cat /tmp/logwatch.ZNR15682/messages  |  /etc/log.d/scripts/shared/onlyservice 'arpwatch' |/etc/log.d/scripts/shared/removeheaders '' |/etc/log.d/scripts/services/arpwatch) 2>&1
root     17208  0.0  0.5  4504 1016 ?        S    04:08   0:00 sh -c ( /bin/cat /tmp/logwatch.ZNR15682/messages  |  /etc/log.d/scripts/shared/onlyservice 'arpwatch' |/etc/log.d/scripts/shared/removeheaders '' |/etc/log.d/scripts/services/arpwatch) 2>&1
root     17209  1.6  0.2  5612  392 ?        D    04:08   0:00 /bin/cat /tmp/logwatch.ZNR15682/messages
root     17210 21.5  0.7  6552 1448 ?        S    04:08   0:04 /usr/bin/perl -w /etc/log.d/scripts/shared/onlyservice arpwatch
root     17211  0.0  0.7  6324 1376 ?        S    04:08   0:00 /usr/bin/perl -w /etc/log.d/scripts/shared/removeheaders
root     17212  0.0  0.7  7036 1344 ?        S    04:08   0:00 /usr/bin/perl -w /etc/log.d/scripts/services/arpwatch
apache   17273  0.2  5.5 38996 10640 ?       S    04:08   0:00 /usr/sbin/httpd
apache   17366  0.0  5.0 38864 9648 ?        S    04:08   0:00 /usr/sbin/httpd
apache   17384  0.0  5.0 38864 9560 ?        S    04:08   0:00 /usr/sbin/httpd
apache   17385  0.0  4.1 38312 7944 ?        S    04:08   0:00 /usr/sbin/httpd

Ps : en fait c'était des heures GMT donc le rpoblème arrive entre 4h et 5h du mat.

[ChezThierry]

Sur ton 'ps aux' on ne compte pas 100% d'utilisation, mais dans les 23% avec 21% venant de logwatch qui est lancé par crontab depuis /etc/cron.daily/00-logwatch

Est-ce que le /var/log/messages de ton serveur est si volumineux qu'il pourrait justifier que son analyse scotch pendant 1h ton serveur ?

[sietjp]

Effectivement le /var/log/messages est vraiment énorme (environ 1Go). J'ai tiny httpd qui met une trace pour chaque reqûete image ce qui fait rapiement grossir le fichier.

Est ce que la taille du /var/log/messages est anormalement grande ? A quoi sert ce logwatch au juste, peut être puis je ne pas le lancer tout simplement?

[sietjp]

Pour infos, cela venait bien de la taille du /var/log/messages . Depuis que j'ai arrêté les traces de thttpd, je n'ai plus de problèmes. Merci à tous de vos conseils.