Mon serveur plante, besoin d'aide pour la lecture de mes logs

[clement106]

Bonjour,

J'ai un gros problème avec mon site. Dès que j'autorise l'accès aux visiteurs, au bout de 5 min mon serveur commence à planté. Je suis alors obligé de passer par l'interface d'OVH pour le redémarrer car le SSH ne fonctionne plus.

J'ai viens de redémarrer en mode rescue-pro et je suis aller voir le fichier syslog mais c'est la première foie que je lis ce type de fichier donc si quelqu'un pourrait m'aider, ça serait vraiment très gentil.

(contenu du fichier log supprimé pour ne pas le laisser en public. Contactez-moi en privé pour l'obtenir)

Vous pouvez le voir en entier ICI

Petites précisions:
- systhème d'exploitation Gentoo Release 2 64 bit (OVH)
- CMS Drupal 6

J'espère vraiment que vous pourrez m'aider... Merci d'avance

 

[jcaron]

Ce serait plus intéressant que tu fasses ça:
- tu te connectes en ssh
- tu lances ton serveur
- tu lances "top"
- tu attends que le serveur plante
- tu nous donnes un copié-collé de ce que top disait avant que la machine n'agonise

Hypothèses vraisemblables:
- ton serveur est à court de RAM et swappe à mort
- ton serveur est à court de CPU

top nous dira lequel des deux (ou éventuellement aucun des deux, mais j'en doute), et quelques autres infos utiles.

Au passage, dis-nous un peu ce que tu as comme serveur exactement, et les valeurs de MaxClients et compagnie dans ton httpd.conf.

Jacques.

 

[ricosound]

Salut.

Pour info, j'ai eu aussi des gros problèmes de plantages de serveur et une partie du problème semblait venir de certains bots qui consommaient trop de ressources.

Un filtrage énergique par le htaccess fait du bien dans ce cas. :mrgreen:

D'autre part, je te déconseille de publier les adresses internes de ton site ; c'est utile pour ceux qui veulent t'aider, mais c'est aussi un point d'entrée pour des pirates. :evil:

Donc édite le message et envoie l'adresse en MP à ceux qui veulent t'aider. comme cela tu sait à qui tu envoie des infos sensibles.

Cordialement, Éric.

 

[clement106]

Merci beaucoup pour vos réponses et votre aide.

Ce serait plus intéressant que tu fasses ça:
- tu te connectes en ssh
- tu lances ton serveur
- tu lances "top"

Voilà c'est fait... j'ai pu remarquer que mysqld occupe souvent 93 - 130 % du processeur. Mon serveur n'a pas encore planté.

Voilà mon fichier httpd.conf

J'ai pris le RPS 3 de chez OVH.

D'autre part, je te déconseille de publier les adresses internes de ton site ; c'est utile pour ceux qui veulent t'aider, mais c'est aussi un point d'entrée pour des pirates. :evil:

Ha oui?? Houps je ne savais pas du tout 8O. Merci pour cette info. Le problème c'est que je n'ai pas le lien pour éditer mon premier message. Bizard.

Un filtrage énergique par le htaccess fait du bien dans ce cas. :mrgreen:

Donc tu veux parler de Google et compagnie?


Je vous donne volontiers encore d'autres infos, j'espère vraiment que je vous pourrez m'aider à résoudre ce problème. Je vous redonne des news dès qu'il commence à planter...

 

[clement106]

Voilà il a planté (il ne répond plus), voici ce que me donne les dernières info de top:

 4645 root      40   0 78660 2420 1096 S    0  0.1   0:04.22 spamd
 7307 root      40   0 10884 1360  796 R    0  0.1   1:23.15 top
11908 hexa50    40   0  112m  18m 5140 D    0  0.9   0:00.59 php
12024 hexa50    40   0 83704  31m 5068 D    0  1.6   0:00.25 php
12036 hexa50    40   0 69152  16m 5068 D    0  0.9   0:00.09 php
12090 hexa50    40   0 66940  14m 5056 D    0  0.8   0:00.10 php
12162 hexa50    40   0 62728  10m 5084 D    0  0.5   0:00.06 php
12166 hexa50    40   0 59604 7300 4408 D    0  0.4   0:00.05 php
12168 hexa50    40   0 57348 4604 3132 D    0  0.2   0:00.02 php
12350 hexa50    40   0 56468 2492 1868 D    0  0.1   0:00.02 php
12389 root      40   0 14280 3288 1436 D    0  0.2   0:00.01 rtm
12399 vpopmail  40   0  2436  328  268 D    0  0.0   0:00.01 qmail-pop3d
12404 root      40   0 12360 2420 1376 D    0  0.1   0:00.01 rtm
    1 root      40   0  2576  508  484 S    0  0.0   0:00.95 init
    2 root      40   0     0    0    0 S    0  0.0   0:00.00 kthreadd
    3 root      RT   0     0    0    0 S    0  0.0   0:00.08 migration/0
    4 root      20   0     0    0    0 S    0  0.0   0:00.00 ksoftirqd/0
    5 root      RT   0     0    0    0 S    0  0.0   0:00.06 migration/1
    6 root      20   0     0    0    0 S    0  0.0   0:00.02 ksoftirqd/1
    7 root      RT   0     0    0    0 S    0  0.0   0:00.04 migration/2
    8 root      20   0     0    0    0 S    0  0.0   0:00.03 ksoftirqd/2
    9 root      20   0     0    0    0 S    0  0.0   0:00.00 events/0
   10 root      20   0     0    0    0 S    0  0.0   0:00.06 events/1
   11 root      20   0     0    0    0 S    0  0.0   0:00.08 events/2
   12 root      20   0     0    0    0 S    0  0.0   0:00.00 cpuset
   13 root      20   0     0    0    0 S    0  0.0   0:00.02 khelper
   19 root      20   0     0    0    0 S    0  0.0   0:00.00 async/mgr
  235 root      20   0     0    0    0 S    0  0.0   0:00.00 sync_supers
  237 root      20   0     0    0    0 S    0  0.0   0:00.00 bdi-default
  238 root      20   0     0    0    0 S    0  0.0   0:00.00 kintegrityd/0
  239 root      20   0     0    0    0 S    0  0.0   0:00.00 kintegrityd/1
  240 root      20   0     0    0    0 S    0  0.0   0:00.00 kintegrityd/2
  241 root      20   0     0    0    0 S    0  0.0   0:00.00 kblockd/0
  242 root      20   0     0    0    0 S    0  0.0   0:00.00 kblockd/1
  243 root      20   0     0    0    0 S    0  0.0   0:00.00 kblockd/2
  244 root      20   0     0    0    0 S    0  0.0   0:00.00 kacpid
  245 root      20   0     0    0    0 S    0  0.0   0:00.00 kacpi_notify
  246 root      20   0     0    0    0 S    0  0.0   0:00.00 kacpi_hotplug
  401 root      20   0     0    0    0 S    0  0.0   0:00.00 ata/0
  402 root      20   0     0    0    0 S    0  0.0   0:00.00 ata/1
  403 root      20   0     0    0    0 S    0  0.0   0:00.00 ata/2
  404 root      20   0     0    0    0 S    0  0.0   0:00.00 ata_aux
  408 root      20   0     0    0    0 S    0  0.0   0:00.00 ksuspend_usbd
  412 root      20   0     0    0    0 S    0  0.0   0:00.00 khubd
  415 root      20   0     0    0    0 S    0  0.0   0:00.00 kseriod
  452 root      20   0     0    0    0 S    0  0.0   0:00.00 rpciod/0
  453 root      20   0     0    0    0 S    0  0.0   0:00.00 rpciod/1
  454 root      20   0     0    0    0 S    0  0.0   0:00.00 rpciod/2
  456 root      20   0     0    0    0 S    0  0.0   0:00.00 kvm-irqfd-clean

 

[jcaron]

Ce qui m'intéresse en premier lieu ce sont les premières lignes en haut du top, qui donnent la RAM et le swap utilisé, le CPU, etc.

Jacques.

 

[clement106]

Hi mince alors...je vais recommencer.

 

[jcaron]

Au vu du reste des infos, on peut deviner que ta machine swappe à mort: tu as déjà des processus php qui font des dizaines de Mo, et tu autorises 150 processus. Si chaque php fait 50 Mo en moyenne, ça fait 150 * 50 Mo = 7.5 Go, et encore, on n'a pas compté les processus httpd, mysql, etc.. Ta machine n'a que 2 Go. Forcément, ça ne rentre pas. Dit autrement, avec 2 Go et 150 processus, sans compter la RAM utilisé par l'OS, mysql, etc, il ne faut pas que les processus httpd+php dépassent 13 Mo. Tu en es loin.

Le premier point c'est que ça veut dire que tu as un problème dans ton php, une des extensions, ou plus vraisemblablement dans le code PHP, ce n'est pas normal qu'un processus php atteigne ce genre de tailles (là tu en as un qui fait 112 Mo!) alors que tu es en mode suphp et que donc chaque instance de php ne gère qu'une seule requête (si j'ai bien tout suivi, moi je suis plutôt mod_perl...).

Ce que tu peux tenter c'est de réduire (considérablement) MaxClients, en le mettant par exemple à 30. Mais je pense que ça ne va pas résoudre le fond du problème.

Commence par vérifier que tu es à jour de tes versions de php, des extensions éventuelles de php et surtout du CMS. Ensuite je pense qu'il faut vérifier le code, il y a doit y avoir quelque part un truc pas cool qui charge des milliards de choses et fait exploser les processus. Pour essayer de trouver quoi, pendant que le serveur est lancé et qu'il commence à grossir, fais un lynx -dump 127.0.0.1/ovh-status et un ps axl régulièrement, puis quand il plante, donne nous le résultat du dernier de chaque, ça permettra de savoir quels processus sont gros et quelles requêtes ils exécutent (il faut évidemment que lynx soit installé sur ta machine).

Tu peux alternativement utiliser ce script:

#!/bin/bash

LOGFILE=/var/log/log_for_jc
while true
do
        echo >>$LOGFILE
        echo "================================================================================================" >>$LOGFILE
        date >>$LOGFILE
        echo "================================================================================================" >>$LOGFILE
        echo >>$LOGFILE
        top -bn1 >>$LOGFILE
        ps axl >>$LOGFILE
        lynx -dump -width 200 127.0.0.1/ovh-status >>$LOGFILE
        sleep 60
done

Une fois que ta machine a planté et que tu l'as rebootée, tu n'as plus qu'à nous balancer la dernière section de /var/log/log_for_jc

Jacques.

 

[ricosound]

Rebonjour.

Le htaccess est un fichier qui édicte des règles de filtrages à l'arrivée sur le site. Dans mon exemple, pour filtrer il suffisait de déclarer un deny des l'adresses IP et du user agent du bot trop gourmand. Dans ce cas, le filtre ne le laisse plus passer.

En fait il y a plein de possibilité de filtrages, il faut prendre son temps pour le maitriser mais c'est très efficace. :mrgreen:

voici un exemple de site sur lequel tu trouveras des explications utiles sur le htacces :

http://www.siteduzero.com/recherche.html?src=htaccess&c=3&x=17&y=8

Bonne étude, Éric.

 

[clement106]

Merci infinement pour vos messages.

Le premier point c'est que ça veut dire que tu as un problème dans ton php, une des extensions, ou plus vraisemblablement dans le code PHP, ce n'est pas normal qu'un processus php atteigne ce genre de tailles

Je crois que vous avez raison, le problème viens surement de là.
Je me suis enfin décidé à installer le module devel correctement (module pour Drupal qui permet d'analyser les performances).
J'ai pu y voir des choses étonnantes... ce module affiche sur chaque page le temps que prend chaque fonction et aussi combien de foie elles exécutes et met en rouge quand c'est anormal. Il y a justement beaucoup de rouge

J'ai fait un test en installant drupal avec les mêmes modules activés mais sans le contenu déjà présent et là aucune erreur et le temps est divisé par deux voir plus. Ça veut bien dire quelque chose...

J'aurais bien voulu faire le test que vous m'avez donné mais dans le stress et un peu d'énervement j'ai tenté d'installer un accélérateur pour php mais je me suis un peu loupé. Le site n'est donc plus vraiment opérationnel.


Pour les robots, je pense aussi que cela pourrait être une bonne solution pour atténuer la chose mais apparemment il y a un réel problème avec php et ce problème sera toujours là avec ou sans robot. Il suffit d'y avoir 50% en plus de visite en une journée pour que le site se remette à planter.

Donc voilà ce que j'ai prévu de faire: je vais passer mon dimanche a ressayer de faire une installation propre de Drupal puis importer mes donnés. Peut-être que le problème pourrait (par miracle) se résoudre de cette manière. Si ce n'est pas le cas, alors je vais rouvrir mon ancien site et prendre tout mon temps pour trouver ce problème.

En tout cas je vous remercie beaucoup d'avoir pris du temps pour m'aider, c'est vraiment sympa.

Salutations.
Clément