Aller au contenu

Plantages incessants sur un serveur dédié OVH


Timale

Sujets conseillés

Salut tout le monde,

Je suis nouveau inscrit ici, mais j'ai déja fait pas mal de recherches dans les différents forums pour essayer de régler les problèmes de mon serveur dédié ...

Une discussion est déja engagée avec un technicien d'OVH, mais comme ils n'ont pas répondu à mon dernier message par la hotline et que le sujet que j'ai posté sur leur forum n'est pas (encore?) validé, alors je me permets de poster ici ... J'espère ne pas trop déranger ! :D

------------------

J'ai un serveur dédié (Intel P4 3.06 GHz - Disque dur 40 Go IDE - 1 Go RAM DDR - Bande passante 80 Mbps) chez OVH ...

Dès le lendemain de la mise en place de la release d'octobre/novembre d'OVH (je ne sais plus de la version), le serveur ns3655.ovh.net qui supportait jusque là la charge des sites (avec forum phpBB) qu'il héberge, plante tous les jours (parfois 2 à 3 fois par jour) !

Depuis ce jour, j'ai travaillé d'arrache pied pour optimiser mes scripts php/Mysql, mais le serveur plante toujours autant.

Ne voyant plus d'où venait le problème, j'ai fait appel à la hotline d'OVH afin de tenter de trouver une solution. Ils m'ont juste demandé de placer "HostNameLookups" sur "Off" dans "httpd.conf" d'apache ... Je l'ai fait mais mais le serveur plante toujours autant.

Voila une petite liste de tout ce que j'ai fait récemment pour tenter de régler le problème:

- installation de iptables il y a environ 1 semaine avec des règles bien définies ... C'est OK !

- "HostNameLookups" sur "Off" dans "httpd.conf" d'apache ... je ne vois pas de différence avec la valeur "on" !

- installation de MRTGSYS pour mieux comprendre le problème ... On voit bien les pics aux moments de plantages: http://ns3655.ovh.net/mrtg/

- le fichier "httpd.conf" d'apache configuré comme suit:

Timeout 300

KeepAlive On

MaxKeepAliveRequests 100

KeepAliveTimeout 15

MinSpareServers 5

MaxSpareServers 10

StartServers 5

MaxClients 250

MaxRequestsPerChild 10

Pour info:

- le port SSH étant bloqué, je n'ai plus les nombreuses tentatives d'intrusions par SSH ...

- les releases sont à jour ...

- il n'y a pas eu d'augmentation conséquente de trafic ... mis à part (peut-être) les robots "inktomisearch" de Yahoo qui scannent en permanence les sites ...

- j'ai les habituels "_vti_bin/owssvr.dll" et "MSOffice/cltreq.asp" dans "error_log" ...

- à part dans les moments de plantage, le serveur reste assez rapide ...

- je ne sais pas trop interpréter les graphs MRTG ... si quelqu'un veut bien me les faire parler, ce n'est pas de refus ! ;)

Je ne sais vraiment plus où chercher ...

D'ailleurs, puisque je ne sais pas interpréter les graphes MRTG, je ne sais même pas si c'est un problème système ou un problème machine ... si ça vient de Apache ou de Mysql ... si c'est un problème de mémoire ou un problème de disque dur ... si ça vient des requêtes effectuées ou du nombre de connectés ...

En tout cas, lorsque je suis présent et que je vois que ça plante, j'arrête Mysql et apache ... j'attends 1 minute ou 2, histoire que la charge descende et je relance Mysql et apache ... Et là, tout redevient normal: le serveur est à nouveau rapide !

Voila les résultats d'un "top" en situation normale:

5:02pm up 4 days, 18:19, 1 user, load average: 1,15, 0,88, 0,81

183 processes: 177 sleeping, 4 running, 2 zombie, 0 stopped

CPU states: 48,2% user, 7,7% system, 0,0% nice, 44,0% idle

Mem: 1031604K av, 962128K used, 69476K free, 0K shrd, 66512K buff

Swap: 522104K av, 25416K used, 496688K free 640248K cached

Euh ... Que dire d'autre ? :rolleyes:

J'ai l'intention d'installer eAccelerator pour espérer diminuer la charge globale de la machine, mais je préfère d'abord trouver la source des plantages ! ;)

Pouvez vous m'aider à trouver le problème des nombreux plantages journaliers, s'il vous plait ?

Merci ...

Cordialement,

Timale

Modifié par Dudu
Lien vers le commentaire
Partager sur d’autres sites

Posté (modifié)
Tu as toujours tes énormes tables de recherches ? ou tu les as viré ?

<{POST_SNAPBACK}>

Euh ... je les ai toujours ! :blush:

J'ai installé un mod (Prune Searchs Tables) qui permet d'alléger les tables de recherche ... je l'avais mis en place mais je n'ai pas désactivé complètement la fonction de recherche ... par peur que les membres ne sachent pas comment retrouver des sujets/messages ...

Une fois la fonction recherche désactivée, tu fais comment pour retrouver les sujets/messages ?

@+

Modifié par Timale
Lien vers le commentaire
Partager sur d’autres sites

  • 2 semaines plus tard...

As-tu essayé de désactiver mod_gzip ?

Il se montre parfois un peu rebelle, ça dépend des pages.

Tu peux valider cette supposition si tu as plusieurs fichiers anciens nommés *.wrk dans le répertoire /tmp.

Regarde les dates de ces fichiers et dis-nous si elles coïncident avec tes moments de galère.

Dan

Lien vers le commentaire
Partager sur d’autres sites

Posté (modifié)
As-tu essayé de désactiver mod_gzip ?

Il se montre parfois un peu rebelle, ça dépend des pages.

Tu peux valider cette supposition si tu as plusieurs fichiers anciens nommés *.wrk dans le répertoire /tmp.

Regarde les dates de ces fichiers et dis-nous si elles coïncident avec tes moments de galère.

Dan

<{POST_SNAPBACK}>

Merci d'avoir répondu ! ;)

Désactiver le mod_gzip ? Ok ! Mais lequel ?

Le mod_gzip d'Apache ou le mod_gzip du forum ?

J'avais désactivé le mod_gzip du forum, mais cette manip me retournait de nombreuses erreurs gzip dans "error_log" d'Apache ...

Oui, lorsque le serveur plante, j'ai le dossier temporaire qui se remplit de plein de fichiers *.wrk

Mais je les vire à chaque fois ...

Cet après-midi j'ai fait un "top" lors du plantage et voila ce que j'ai comme info:

2:03pm  up 1 day,  8:33,  2 users,  load average: 20,06, 42,53, 26,02

195 processes: 191 sleeping, 4 running, 0 zombie, 0 stopped

CPU states:  5,9% user, 42,5% system,  0,0% nice, 51,5% idle

Mem:  1031604K av,  875176K used,  156428K free,       0K shrd,    3984K buff

Swap:  522104K av,  327300K used,  194804K free                   72964K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND

6930 nobody    17   0  129M 104M  2660 D     5,1 10,3   0:18 httpd

10160 nobody    16   0  123M  34M  2640 R     3,7  3,4   0:06 httpd

20892 nobody     9   0  7812 7168  3060 S     1,9  0,6   0:00 httpd

20641 nobody    12   0  123M  30M  2888 R     1,7  3,0   0:06 httpd

13188 root      13   0  1184 1184   832 R     1,7  0,1   0:01 top

13809 mysql     10   0 21308  16M  1788 D     1,7  1,5   0:00 mysqld

22710 mysql     11   0 21308  16M  1788 S     1,7  1,5   0:00 mysqld

12420 nobody     9   0  7700 7068  3036 S     1,3  0,6   0:00 httpd

10659 mysql     10   0 21308  16M  1788 S     1,1  1,5   0:00 mysqld

14549 nobody    11   0  7824 7180  3088 S     0,9  0,6   0:00 httpd

20904 root       4   0  1768  392   348 S     0,3  0,0   0:02 httpd

29429 mysql      9   0 21308  16M  1788 S     0,3  1,5   0:00 mysqld

23483 mysql     12   0 21308  16M  1788 S     0,1  1,5   0:00 mysqld

20698 nobody    10   0 84892 8888  2976 D     0,1  0,8   0:05 httpd

    1 root       8   0   128   84    84 S     0,0  0,0   0:04 init

    2 root       9   0     0    0     0 SW    0,0  0,0   0:00 keventd

    3 root      19  19     0    0     0 SWN   0,0  0,0   0:09 ksoftirqd_CPU0

    4 root       9   0     0    0     0 SW    0,0  0,0   0:14 kswapd

    5 root       9   0     0    0     0 SW    0,0  0,0   0:00 bdflush

    6 root       9   0     0    0     0 SW    0,0  0,0   0:01 kupdated

    7 root       9   0     0    0     0 SW    0,0  0,0   0:00 scsi_eh_0

    8 root       9   0     0    0     0 SW    0,0  0,0   0:00 scsi_eh_1

    9 root      -1 -20     0    0     0 SW<   0,0  0,0   0:00 mdrecoveryd

   10 root       9   0     0    0     0 SW    0,0  0,0   4:15 kjournald

15166 root       9   0     0    0     0 SW    0,0  0,0   8:40 kjournald

12313 root       9   0   628  428   428 S     0,0  0,0   0:00 sshd

29045 root       9   0   524  464   444 S     0,0  0,0   0:00 syslogd

10721 root       9   0   484  464   424 S     0,0  0,0   0:00 klogd

2306 named      9   0  2564 2268  1800 S     0,0  0,2   0:00 named

11891 named      9   0  2564 2268  1800 S     0,0  0,2   0:02 named

11994 named      9   0  2564 2268  1800 S     0,0  0,2   0:09 named

2354 named      9   0  2564 2268  1800 S     0,0  0,2   0:00 named

25629 named      9   0  2564 2268  1800 S     0,0  0,2   0:01 named

5930 root       9   0   620  432   432 S     0,0  0,0   0:00 xinetd

  891 qmails     9   0   404  376   356 S     0,0  0,0   0:03 qmail-send

27452 qmaill     9   0   364  316   316 S     0,0  0,0   0:00 multilog

23817 root       9   0   416  348   348 S     0,0  0,0   0:00 tcpserver

19456 qmaill     4   0   444  388   380 S     0,0  0,0   0:00 tcpserver

32324 qmaill     9   0   288  248   248 S     0,0  0,0   0:00 tai64n

3264 root      14   0   332  300   276 S     0,0  0,0   0:00 qmail-lspawn

7245 qmailr     9   0   344  312   304 S     0,0  0,0   0:00 qmail-rspawn

1558 qmailq     9   0   348  320   292 S     0,0  0,0   0:00 qmail-clean

23038 root       9   0   484  392   392 S     0,0  0,0   0:00 couriertcpd

32350 root       9   0   324  276   276 S     0,0  0,0   0:00 courierlogger

19472 daemon     9   0   460  392   392 S     0,0  0,0   0:00 atd

19997 root       4   0   516  516   452 S     0,0  0,0   0:02 watchdog

30495 root       9   0   144  108   108 S     0,0  0,0   0:01 clockspeed

11888 root       9   0  3692  760   724 S     0,0  0,0   0:01 miniserv.pl

4604 root       9   0   124   64    64 S     0,0  0,0   0:00 mingetty

26896 root       9   0   124   64    64 S     0,0  0,0   0:00 mingetty

24294 root       9   0   124   64    64 S     0,0  0,0   0:00 mingetty

@+

Modifié par Timale
Lien vers le commentaire
Partager sur d’autres sites

Le mod_gzip... c'est celui d'apache que je parle.

Il suffit d'éditer le fichier httpd.conf et mettre gzip à off.

Et stoppe aussi celui de PhpBB....

Ensuite redémarre Apache.

Tu as énormément de swap sur ton serveur, et les process qui "bouffent" le plus sont les httpd.

J'opterais pour mod_gzip.

Dan

Lien vers le commentaire
Partager sur d’autres sites

En éditant httpd.conf, j'ai ça:

mod_gzip_on yes

mod_gzip_dechunk yes

mod_gzip_keep_workfiles No

mod_gzip_temp_dir /tmp

Dois-je le modifier ainsi:

mod_gzip_on No

mod_gzip_dechunk yes

mod_gzip_keep_workfiles No

mod_gzip_temp_dir /tmp

@+

Lien vers le commentaire
Partager sur d’autres sites

Posté (modifié)

Bon ! J'ai fait le changement dans apache en plus de l'avoir fait dans phpBB et effectivement, je n'ai plus les messages d'erreurs suivants dans error_log:

[Fri May 19 20:28:03 2006] [error] mod_gzip: TRANSMIT_ERROR:104

[Fri May 19 20:28:13 2006] [error] mod_gzip: TRANSMIT_ERROR:104

[Fri May 19 20:28:52 2006] [error] mod_gzip: TRANSMIT_ERROR:104

[Fri May 19 20:29:09 2006] [error] mod_gzip: TRANSMIT_ERROR:104

[Fri May 19 20:29:15 2006] [error] mod_gzip: TRANSMIT_ERROR:ISMEM:104

[Fri May 19 20:29:34 2006] [error] mod_gzip: TRANSMIT_ERROR:104

[Fri May 19 20:35:13 2006] [error] mod_gzip: TRANSMIT_ERROR:104

Maintenant, ne voulant pas crier victoire trop vite, je vais tester sur plusieurs jours pour voir ! ;)

Et quelque soit les résultats du test, je les posterai ici ! ;)

Merci Dan,

@+ :)

Modifié par Timale
Lien vers le commentaire
Partager sur d’autres sites

  • 2 semaines plus tard...
Posté (modifié)

Bon ! malgré les changements ci-dessus, le serveur a continué à tomber 2 ou 3 fois par jour de façon aléatoire ...

J'ai continué à traquer les éventuels bugs et j'ai trouvé un bug très conséquent sur un mod de phpBB que j'utilise: le mod impression de sujet (printview) ...

Ce mod permet de rassembler sur une même page les différents messages d'un sujet afin de les imprimer ... Lorsque le sujet en question ne contient pas énormément de messages, ça va ... Mais lorsque vous avez des sujets qui se remplissent inlassablement de plusieurs milliers de messages, là, ça peut foirer en heure de pointe ... J'ai des sujets qui font plus de 15000 messages ! :wacko:

Alors lorsqu'on demande au systeme de rassembler 15000 messages sur une seule page, ça prend beaucoup de temps en occupant un maximum de ressources du serveur qui commence à ralentir ... Si en même temps, c'est l'affluence sur le site, alors le serveur jette l'éponge ! :sick:

J'ai donc modifié ce mod afin de découper le sujet en plusieurs pages moins consommatrices de CPU ... Et là, ça allait beaucoup mieux ...

Aujourd'hui, lorsque je regarde les graphes MRTG, c'est beaucoup mieux ! ;)

Et le serveur n'a pas planté depuis cette modif ...

Merci tout de même à tous ceux qui m'ont aidé à régler mes problèmes !

@+ ;)

Modifié par Timale
Lien vers le commentaire
Partager sur d’autres sites

Donc ce n'est pas "un plantage incessant sur un serveur dédié OVH" qu'il fallait mettre en titre, mais "Une mod de PhpBB met le souk" :!:

Ce à quoi je rajouterais : "ce n'est ni la première, ni la dernière" :)

Lien vers le commentaire
Partager sur d’autres sites

Veuillez vous connecter pour commenter

Vous pourrez laisser un commentaire après vous êtes connecté.



Connectez-vous maintenant
×
×
  • Créer...