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

**le Lun Fév 20, 2006 16:48**

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é?

**le Lun Fév 20, 2006 16:57**

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

**le Lun Fév 20, 2006 16:58**

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.

**le Lun Fév 20, 2006 17:00**

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

**le Lun Fév 20, 2006 17:16**

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.

**le Lun Fév 20, 2006 17:20**

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.

**le Lun Fév 20, 2006 17:32**

leffred a écrit: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

**le Lun Fév 20, 2006 17:37**

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

**le Lun Fév 20, 2006 18:39**

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.

**le Lun Fév 20, 2006 20:43**

thierry8 a écrit: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.

**le Mar Fév 21, 2006 11:34**

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.

**le Mar Fév 21, 2006 12:47**

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 ?

**le Mar Fév 21, 2006 13:44**

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?

**le Ven Mar 10, 2006 14:10**

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.

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

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

Formation recommandée sur ce thème :

Lectures recommandées sur ce thème :

Qui est en ligne