[RESOLU] Crash Serveur - ovh

Support Debian
#1

Bonjour à tous,

Après pas mal de recherches ici-même, je n’ai toujours pas trouvé la solution à mon souci.

Voici ce qui m’arrive :

Un serveur chez ovh (le plus léger possible, un RPS à 512 de RAM) crash plus ou moins fréquemment. A part quelques bases de données simples, j’ai également un Wordpress de configuré dessus. L’ensemble des mises à jours sont passées et installée.

Voici les différents paquets installés :

[ul]apache2 -> 2.2.9[/ul]
[ul]mysql-server-5.0 -> 5.0.51[/ul]
[ul]proftpd -> 1.3.1[/ul]

[quote]uname -a
Linux rXXX.ovh.net 2.6.32.2-xxxx-grs-ipv4-32 #1 SMP Tue Dec 29 14:41:18 UTC 2009 i686 GNU/Linux
[/quote]

le reste n’est pas vraiment passionnant.

Mon serveur plante régulièrement :

  • ssh inaccessible, parfois le login de demandé mais jamais le password
  • apache qui tourne mais qui mouline
  • mysql de planté

En gros, je lance un reboot hardware depuis la console OVH pour récupérer la main.

mon syslog n’a rien de noté sur la dernière ligne avant le reboot, toutefois rien de bien méchant. Dernière lignes avant crash :

[quote]Feb 14 14:33:35 r27568 snmpd[3706]: cannot open /proc/net/dev …
Feb 14 14:33:40 rXXX /USR/SBIN/CRON[10666]: (root) CMD (/usr/local/rtm/bin/rtm 0 > /dev/null 2> /dev/null)
Feb 14 14:33:50 rXXX snmpd[3706]: cannot open /proc/net/dev …
Feb 14 14:33:59 rXXX snmpd[3706]: cannot open /proc/net/snmp …
Feb 14 14:34:05 rXXX snmpd[3706]: cannot open /proc/net/dev …
Feb 14 14:34:20 rXXX snmpd[3706]: cannot open /proc/net/dev …
Feb 14 14:34:35 rXXX snmpd[3706]: cannot open /proc/net/dev …
Feb 14 14:36:23 rXXX kernel: imklog 3.18.6, log source = /proc/kmsg started.
[/quote]

Le mysql log les requêtes lentes volontairement, mais la dernière de loguée n’est jamais la même requête, par contre elle provient toujours du moteur Wordpress.

le reste des fichiers de logs que je connais (messages.log, kernel.log, proftpd.log) n’annoncent rien non plus.

Du coup, la vraie question est la suivante : que puis-je mettre en place pour comprendre ce qui ne va pas au moment où ça plante, en sachant que je n’ai plus la main sur la machine ? (physiquement chez ovh, serveur virtuel).

Merci de m’avoir lu, et bon début de semaine à tous :slightly_smiling:

Edit : ça n’est pas un soucis d’espace disque, celui-ci n’est plein qu’à 14%.

#2

Tu peux redémarrer ton RPS en mode rescue afin de faire quelques tests cpu, mémoire, etc via les outils OVH.
Si rien, redémarre sur debian et installes des paquets de monitoring système comme munin par exemple :
aptitude install munin et rends toi sur ipdetamachine/munin (mise à jour toutes les cinq minutes).

#3

Bonjour Niloo, et merci pour ta réponse !

J’install munin de ce pas et je check cette nuit via les outils ovh. Pas mal de sites en prod qui tournent là dessus, déjà qu’ils prennent chers sans mes intervention, si en plus je les crash volontairement en journée… ^^

Je vous tiendrais au courant, j’aurais peut-être besoin de vous pour finaliser l’analyse de la chose :wink:

#4

Bonjour Bonjour !

Alors, nouveau plantage de part chez moi. Les outils OVH n’ont rien donné d’intéressant.

Le munin est très sympa pour suivre les courbes (ça ressemble à du cacti plus véloce ^^), mais lorsque le serveur reboot, il perd ses stats (je regarde si je peux pas paramétrer cela en même temps).

Lorsque je check chez ovh l’état actuel du serveur pendant qu’il est planté, la RAM et le CPU sont à 100%. J’ai donc bien un process qui chie tout… Et le “top five” des process ne me remonte que du sql (120-130Mo), du bind (50Mo) et du apache2.

Auriez-vous une autre idée pour tenter de trouver le process qui vient me bouffer 100% de ma ram et de mon CPU, avec toujours la même contrainte de ne pouvoir y accéder pendant un plantage ?

Merci à vous

#5

Dans toutes les installations de munin que j’ai fait, tout est garder même après un redémarrage de la machine.
Les fichiers ne seraient-il pas stockés dans un tmpfs ou équivalent ?

Pour en savoir la cause, il faudrait que munin fonctionne pour voir si c’est du DOS, du segment fault ou bien simple fait que l’addition de RPS + MySQL + trafic = plantage.
MySQL fait pas mal d’accès disque et le RPS a des disques distants donc latence.

Passe un coup de tuning-primer, c’est un script qui regarde si la configuration de ton serveur MySQL est correct.
Si tu as de la ram en stocke met le dossier /tmp en tmpfs.

Concernant apache2, utilises-tu un opcache pour alléger le serveur ?

Les plantages arrivent vers quelles heures en générale ?

#6

Merci, je me penche dessus ce soir, des p’tits soucis au boulot, mais merci de ta réponse :wink:

#7

Je pense avoir trouvé le problème :

Je suis tout pourri en paramétrage Apache ^^

En trouvant cet article, j’ai pu faire quelques tests :

blog.gaetan-grigis.eu/systeme/co … e-au-poil/

Et c’est bien mon apache qui gardait des connexions bien trop longues, sans les killer de lui-même, d’où la saturation régulière de la ram, et l’inaccessibilité au serveur (ou mon impatience ^^)

Merci Niloo pour ton aide, tu m’a mis sur la bonne piste :wink:

Sujet résolu :slightly_smiling: