Le Forum Non Officiel de la DEDIBOX
Vous n'êtes pas identifié.
A 3 reprises apache a eu des problèmes sur ma dedibox, mes sites deviennent inaccessible, le navigateur cherchait la page en permanence sans afficher aucune erreur. J'ai rien trouver dans les logs ... La seule solution que j'ai trouvé est d'arrêter et de relancer apache, pas très pratique :+ .
Quelqu'un a t-il connu le même problème ? Ou connaissez vous la solution ?
Je vous remercie ![]()
Hors ligne
Il répond en telnet lors de ses phases d'autisme ?
Hors ligne
C'est pas ce que je demandais/suggérais.
Lorsque ton apache fait l'autiste, est-ce que tu peux te connecter avec telnet ou netcat dessus (port 80, donc) et voir s'il répond, envoyer une requête HTTP à la main et voir s'il envoie un début de réponse ?
Ca permettrait de voir si c'est carrément niveau socket que ca vautre ou si c'est à l'émission du contenu.
Hors ligne
Ca affecte le contenu statique (html, images) ?
Un "top" donne quand, qd le phénomène apparaît ?
Hors ligne
Ah nan de nouveau ca ne marche pas, en fait on dirait que le serveur est surchargé et qu'on attends la connection, une fois connecté c'est bon mais des qu'on attends quelques secondes, on perds la connection et c'est de nouveau impossible ![]()
Hors ligne
Tu as beaucoup d'accès au site ?
Si tu n'envoies pas de requête en telnet, c'est normal qu'apache te dégage.
Si y a un certain trafic, ca pourrait éventuellement mener à un manque de process apache dispos pour répondre. Lorsque ton apache fait l'autiste:
$ ps aux|grep apache2 | grep -v grep | wc -l
Ca te donnera le nombre de process apache qui tournent. Si ce nombre est constamment au niveau du MaxClients configuré, c'est qu'il faut sans doute autoriser ton apache à forker un peu plus !
Bref, si le problème vient du nombre trop important de connexions, tu peux jouer là dessus::
MaxClients 64
==> d'origine ca doit être dans les 20, pas forcément suffisant si on a pas mal d'accès concurrents avec des requêtes un peu longues.
MaxRequestsPerChild 40
==> Ca limite le nombre de requêtes max pour une seule connexion (en HTTP 1.1). Ca peut éventuellement réduire le bouchonnage si tu as des clients tardent à fermer leurs connexions... Bon 40 c'est pas grand chose, mais pour du web ca peut servir. De toute façon c'est pour debugger
KeepAliveTimeout 5
==> On réduit le timeout pour encore réduire le nombre de serveurs monopolisés à rien faire. Ca peut faire un peu mal pour des clients qui ont des connexions à la rue.
Là c'est des tatonnements pour voir si ca aide, après faudra tuner plus finement, si les premiers résultats s'avèrent probant dans cette voie.
Hors ligne
root@dedibox:~# ps aux|grep apache2 | grep -v grep | wc
11 143 902
Pourais tu me dire a quoi correspondent ces chiffres ?
Voila ce que j'obtient. Bizarrement le problème ne se produit pas aux heures de pointes et puis je n'ai pas un gros traffic. J'ai environ 2000 visiteurs/jours pas plus.
En tout ca merci Calimero ![]()
Hors ligne
Essayes de nous poser les logs, surtout error.log.
A la limite, meme syslog et message, ca peu aider.
Je dirais meme un "ps auxf", histoire de voir tout ce qui tourne sur ta machine, et enfin classique, la conf d'apache afin de voir s'il n'y a pas d'incohérence.
Hors ligne
Sky a écrit:
root@dedibox:~# ps aux|grep apache2 | grep -v grep | wc
11 143 902
Pourais tu me dire a quoi correspondent ces chiffres ?
Voila ce que j'obtient. Bizarrement le problème ne se produit pas aux heures de pointes et puis je n'ai pas un gros traffic. J'ai environ 2000 visiteurs/jours pas plus.
En tout ca merci Calimero
tu as 11 process apache.
en gros rien d'extraordinaire.
ps: a tu es le fameux Sky de plop, enchanté :p
Hors ligne
Effectivement, pas de quoi fouetter un chat, 11 petits process... Mhhh c'était pourtant séduisant comme idée (car facile à résoudre
).
wc permet de compter les lignes (1er chiffre), les mots (2ème), les caractères.
Avec l'option -l comme je l'indiquais, ca affiche que les lignes.
Bon, pour ton problème, je commence à être à cours d'idées. :ph34r: Mais je ne suis pas un puits de science. ![]()
Comme le suggère DjinnS, poste nous le maximum de logs (ou mets les qq parts visibles en ligne) pour qu'on puisse jeter un coup d'oeil.
Dernière modification par Calimero (2006-06-20 23:13:03)
Hors ligne
Je n'ai rien d'interessant dans les logs d'apache et comme vous venez de me le dire, apache est loin d'etre fatigué ![]()
Quand je fais "dmesg" j'ai :
UDP: bad checksum. From 218.102.189.22:34262 to 88.191.13.86:4665 ulen 14
UDP: bad checksum. From 219.148.40.118:38703 to 88.191.13.86:4665 ulen 14
UDP: bad checksum. From 219.146.219.13:9057 to 88.191.13.86:4665 ulen 14
UDP: bad checksum. From 200.67.12.217:61552 to 88.191.13.86:4665 ulen 290
UDP: bad checksum. From 218.102.189.22:34328 to 88.191.13.86:4665 ulen 58
UDP: bad checksum. From 195.210.252.135:35663 to 88.191.13.86:4665 ulen 30
UDP: bad checksum. From 221.202.224.2:52535 to 88.191.13.86:4665 ulen 14
UDP: bad checksum. From 222.216.111.138:10111 to 88.191.13.86:4665 ulen 14
UDP: bad checksum. From 82.9.247.161:1542 to 88.191.13.86:4665 ulen 550
UDP: bad checksum. From 219.236.78.235:1796 to 88.191.13.86:4665 ulen 290
UDP: bad checksum. From 66.188.173.9:64591 to 88.191.13.86:4665 ulen 14
UDP: bad checksum. From 218.28.65.115:64849 to 88.191.13.86:4665 ulen 14
UDP: bad checksum. From 221.202.224.56:31136 to 88.191.13.86:4665 ulen 14
UDP: bad checksum. From 80.109.180.75:35929 to 88.191.13.86:4665 ulen 26
UDP: bad checksum. From 221.202.224.12:50579 to 88.191.13.86:4665 ulen 14
UDP: bad checksum. From 221.13.96.28:32347 to 88.191.13.86:4665 ulen 14
UDP: bad checksum. From 68.9.175.163:1187 to 88.191.13.86:4665 ulen 510
UDP: bad checksum. From 218.26.12.23:45036 to 88.191.13.86:4665 ulen 14
UDP: bad checksum. From 221.12.171.93:26651 to 88.191.13.86:4665 ulen 14
UDP: bad checksum. From 86.1.71.36:45161 to 88.191.13.86:4665 ulen 310
UDP: bad checksum. From 61.187.55.37:65007 to 88.191.13.86:4665 ulen 14
UDP: bad checksum. From 221.12.171.76:14696 to 88.191.13.86:4665 ulen 14
UDP: bad checksum. From 86.207.0.153:63543 to 88.191.13.86:4665 ulen 14
UDP: bad checksum. From 86.207.0.153:63543 to 88.191.13.86:4665 ulen 14
UDP: bad checksum. From 219.144.222.247:46817 to 88.191.13.86:4665 ulen 14
UDP: bad checksum. From 83.160.157.88:36176 to 88.191.13.86:4665 ulen 26
UDP: bad checksum. From 211.138.246.3:56571 to 88.191.13.86:4665 ulen 14
UDP: bad checksum. From 218.7.204.3:23830 to 88.191.13.86:4665 ulen 14
UDP: bad checksum. From 218.71.239.67:46804 to 88.191.13.86:4665 ulen 14
Pour le port 4665, je pense que c'est du au fait que j'ai tester un serveur edonkey pendant quelques jours, mais maintenant c'est terminé ... Je pense qu'il y a un rapport nan ? Il y aurais pas une sorte de maximum de connections ?
Merci a vous deux ![]()
Djins, de meme :p ( je m'en vais de ce pas sur ton blog )
Hors ligne