Timale Posté 6 Mai 2006 Posté 6 Mai 2006 (modifié) 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 ! ------------------ 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 ? 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é 17 Août 2007 par Dudu
Enz0 Posté 6 Mai 2006 Posté 6 Mai 2006 Tu as toujours tes énormes tables de recherches ? ou tu les as viré ?
Timale Posté 6 Mai 2006 Auteur Posté 6 Mai 2006 (modifié) Tu as toujours tes énormes tables de recherches ? ou tu les as viré ? <{POST_SNAPBACK}> Euh ... je les ai toujours ! 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é 6 Mai 2006 par Timale
Dan Posté 19 Mai 2006 Posté 19 Mai 2006 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 Posté 19 Mai 2006 Auteur Posté 19 Mai 2006 (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,02195 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é 19 Mai 2006 par Timale
Dan Posté 19 Mai 2006 Posté 19 Mai 2006 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 Posté 19 Mai 2006 Auteur Posté 19 Mai 2006 En éditant httpd.conf, j'ai ça: mod_gzip_on yesmod_gzip_dechunk yes mod_gzip_keep_workfiles No mod_gzip_temp_dir /tmp Dois-je le modifier ainsi: mod_gzip_on Nomod_gzip_dechunk yes mod_gzip_keep_workfiles No mod_gzip_temp_dir /tmp @+
Dan Posté 19 Mai 2006 Posté 19 Mai 2006 Ben oui, c'est tout ce qu'il faut changer ... redémarre apache ensuite !
Timale Posté 19 Mai 2006 Auteur Posté 19 Mai 2006 (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é 19 Mai 2006 par Timale
Timale Posté 1 Juin 2006 Auteur Posté 1 Juin 2006 (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 ! 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 ! 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é 1 Juin 2006 par Timale
Dan Posté 1 Juin 2006 Posté 1 Juin 2006 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"
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant