Version complète: sur le forum Webmaster Hub : Plantages incessants sur un serveur dédié OVH
Webmaster Hub > Informatique & Internet > PC-Gyver
Timale
samedi 6 mai 2006 à 16:09
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 ! biggrin.gif

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

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 ! wink.gif

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.gif

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 ! wink.gif

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

Merci ...

Cordialement,
Timale
Enz0
samedi 6 mai 2006 à 16:17
Tu as toujours tes énormes tables de recherches ? ou tu les as viré ?
Timale
samedi 6 mai 2006 à 17:18
CITATION(Enz0 @ samedi 06 mai 2006, 17h17)
Tu as toujours tes énormes tables de recherches ? ou tu les as viré ?
*


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

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 ?

@+
Enz0
samedi 6 mai 2006 à 18:50
Si tes pages sont dans Google, tu mets l'outil de Google ! whistling.gif
Dan
vendredi 19 mai 2006 à 18:40
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
Timale
vendredi 19 mai 2006 à 19:20
CITATION(Dan @ vendredi 19 mai 2006, 19h40)
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
*


Merci d'avoir répondu ! wink.gif

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:

CITATION
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



@+
Dan
vendredi 19 mai 2006 à 19:30
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
Timale
vendredi 19 mai 2006 à 19:51
En éditant httpd.conf, j'ai ça:

CITATION
mod_gzip_on yes
mod_gzip_dechunk yes
mod_gzip_keep_workfiles No
mod_gzip_temp_dir /tmp


Dois-je le modifier ainsi:

CITATION
mod_gzip_on No
mod_gzip_dechunk yes
mod_gzip_keep_workfiles No
mod_gzip_temp_dir /tmp


@+
Dan
vendredi 19 mai 2006 à 21:23
Ben oui, c'est tout ce qu'il faut changer smile.gif

... redémarre apache ensuite !
Timale
vendredi 19 mai 2006 à 21:51
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:

CITATION
[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 ! wink.gif

Et quelque soit les résultats du test, je les posterai ici ! wink.gif

Merci Dan,

@+ smile.gif
Timale
jeudi 1 juin 2006 à 14:28
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.gif
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.gif
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 ! wink.gif
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 !

@+ wink.gif
Dan
jeudi 1 juin 2006 à 14:44
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" q_smallexcla.gif

Ce à quoi je rajouterais : "ce n'est ni la première, ni la dernière" smile.gif
Ceci est une version "bas débit" de notre forum. Pour voir la version complète avec plus d'information, la mise en page et les images, veuillez cliquer ici.