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

Discussion dans 'Administration d'un site Web' créé par clement106, 2 Octobre 2010.

  1. clement106
    clement106 WRInaute discret
    Inscrit:
    5 Avril 2007
    Messages:
    78
    J'aime reçus:
    0
    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 ;)
     
  2. jcaron
    jcaron WRInaute accro
    Inscrit:
    13 Février 2004
    Messages:
    2 593
    J'aime reçus:
    0
    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.
     
  3. ricosound
    ricosound WRInaute occasionnel
    Inscrit:
    25 Octobre 2009
    Messages:
    447
    J'aime reçus:
    0
    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.
     
  4. clement106
    clement106 WRInaute discret
    Inscrit:
    5 Avril 2007
    Messages:
    78
    J'aime reçus:
    0
    Merci beaucoup pour vos réponses et votre aide.

    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.

    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.

    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...
     
  5. clement106
    clement106 WRInaute discret
    Inscrit:
    5 Avril 2007
    Messages:
    78
    J'aime reçus:
    0
    Voilà il a planté (il ne répond plus), voici ce que me donne les dernières info de top:

    Code:
    
     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
    
     
  6. jcaron
    jcaron WRInaute accro
    Inscrit:
    13 Février 2004
    Messages:
    2 593
    J'aime reçus:
    0
    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.
     
  7. clement106
    clement106 WRInaute discret
    Inscrit:
    5 Avril 2007
    Messages:
    78
    J'aime reçus:
    0
    Hi mince alors...je vais recommencer.
     
  8. jcaron
    jcaron WRInaute accro
    Inscrit:
    13 Février 2004
    Messages:
    2 593
    J'aime reçus:
    0
    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:
    Code:
    #!/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.
     
  9. ricosound
    ricosound WRInaute occasionnel
    Inscrit:
    25 Octobre 2009
    Messages:
    447
    J'aime reçus:
    0
    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.
     
  10. clement106
    clement106 WRInaute discret
    Inscrit:
    5 Avril 2007
    Messages:
    78
    J'aime reçus:
    0
    Merci infinement pour vos messages.

    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
     
Chargement...
Similar Threads - serveur plante besoin Forum Date
Apache 2 sature mémoire puis plante serveur Administration d'un site Web 31 Mars 2012
Noyé par les requêtes de google: Tous mon serveur plante (CPU, RAM et SWAP à 99%) Problèmes de référencement spécifiques à vos sites 17 Avril 2011
Attaque béton qui plante le serveur en 403 Développement d'un site Web ou d'une appli mobile 25 Avril 2010
Htaccess plante après migration serveur Administration d'un site Web 18 Avril 2010
mon serveur plante chaque deux jours le nombre de mes visiteurs est de ... Administration d'un site Web 29 Juillet 2009
Mon serveur OVH encore planté Administration d'un site Web 26 Mars 2009
Serveurs et NDD en fonction du pays ? qu'en pensez-vous ? Débuter en référencement 25 Septembre 2019
Quels ports accepter/refuser - serveur VPS. Administration d'un site Web 28 Août 2019
Codeur avec leur propre serveurs/hébergeurs Administration d'un site Web 11 Août 2019
Annuaire de serveurs minecraft Annuaires et moteurs 1 Août 2019
  1. Ce site utilise des cookies. En continuant à utiliser ce site, vous acceptez l'utilisation des cookies.
    Rejeter la notice