Plantages serveur incessants sur un dédié OVH

[Amibien]

Bonjour à tous,

Je fais appel à vos connaissances car depuis trois mois, notre serveur dédié plante de plus en plus souvent et le support OVH semble galérer pour résoudre le problème :'(

Le problème est le suivant :

Sans prévenir la base mysql devient inacessible, il m'est alors impossible de redémarrer le serveur via l'admin. La seule solution à mon niveau est de rebooter la machine.

Suite à ces plantage, je vous dresse la liste des opérations effectuées (vous remarquerez que certaines sont bien étonnantes vis à vis de la panne)

Voici le détail de l'intervention réalisée:

2006-04-1 17:32:50 - Votre serveur ne ping plus

2006-04-01 18:03:09 - Thibault prends en charge l'intervention

2006-04-01 18:03:25 - Thibault a fait: Remplacement de l alimentation

alim hs

installation d'une nouvelle alim

ping ok ssh ok

Voici le détail de l'intervention réalisée:

2006-03-25 00:16:08 - Votre serveur ne ping plus

2006-03-25 00:22:20 - khaled prends en charge l'intervention

2006-03-25 00:27:41 - khaled a fait: Remplacement de l alimentation

Alimentation HS, changement du bloc d'alim,

vérification du cpu ok,

le serveur est sur login, port SSH open,ping ok.

Voici le détail de l'intervention réalisée:

2006-03-24 18:50:45 - Votre serveur ne ping plus

2006-03-24 20:53:06 - cedric prends en charge l'intervention

2006-03-24 21:29:43 - cedric a fait: Remplacement par un spare

SYSTEME de refroidissment hs. remplacer.serveur remplacer par un sapre. ping ok sur login

Voici le détail de l'intervention réalisée:

merci de verifier la RAM de ce serveur qui plante avec des messages d alerte sur la ram

Date:  2006-03-24 18:42:58 cedric a fait: Vérification du serveur

remplacement de la ram, car erreur dans les log. ping ok sur login . ssh open

Voici le détail de l'intervention réalisée:

2005-11-17 04:38:31 - Votre serveur ne ping plus

2005-11-17 05:04:00 - cedric prends en charge l'intervention

2005-11-17 05:22:09 - cedric a fait: Remplacement de l alimentation

alim hs remplacer;ping ok sur login

Nous avons le plaisir de vous annoncer que l'intervention

sur votre serveur ns31893.ovh.net s'est terminiee avec succes.

Pour rappel, il ete realise sur votre serveur:

- upgrade de la ram

Date de debut d'intervention: 2005-06-27 11:59:52

Date de fin d'intervention: 2005-06-27 12:02:44

Bilan, en quatre mois, trois alim, de la ram, un spare... Je trouve que celà commence à faire beaucoup et j'en appelle donc à vos expériences.

Je note régulièrement le même message d'erreur avant que la base (puis le serveur) plante.

Ce message est le suivant :

Apr  1 16:04:30 ns31893 kernel: VM: killing process httpd

Apr  1 16:04:50 ns31893 kernel: __alloc_pages: 0-order allocation failed (gfp=0xf0/0)

Apr  1 16:05:21 ns31893 last message repeated 5 times

Apr  1 16:06:31 ns31893 last message repeated 10 times

Apr  1 16:06:53 ns31893 last message repeated 4 times

Apr  1 16:08:00 ns31893 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)

Apr  1 16:08:02 ns31893 kernel: VM: killing process httpd

Apr  1 16:08:02 ns31893 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)

Apr  1 16:08:02 ns31893 kernel: VM: killing process httpd

Je vous en prie heeeeeeeeelp

Modifié 1 Avril 2006 par Amibien

[Dan]

A mon avis, c'est tout simple:

MySql utilise /tmp comme répertoire temporaire, et si tu as de très grosses requêtes elles peuvent nécessiter pas mal d'espace.

Donc pour une grosse base avec des requêtes non-optimisées, le risque est réel;

Il suffit de créer un répertoire dans un filesystem où tu as de l'espace libre (/home/tmp/mysql ou /home/tmp par exemple) et modifier le fichier de démarrage /etc/init.d/mysql pour ajouter après la ligne:

export PATH

TMPDIR=/home/tmp/mysql

export TMPDIR

Ensuite tu redémarres mysql

Dan

PS: pense à donner les droits corrects à ce nouveau répertoire: Utilisateur mysql, groupe mysql !

[Amibien]

Merci pour cette info Dan.

Ce qui m'étonne quand même c'est que la base est loin d'être grosse (10-15 mo !) et j'imaginais qu'un dédié dans une conf de base était capable de gérer un trafic vraiment pas exagéré du style un millier de visiteurs par jour...

Tu penses toujours que celà peut en être la cause avec de si faibles données ?

[Dan]

En tout cas cela ne te prend que 2 minutes à mettre en place...

Donc ce n'est pas vraiment contraignant

Il te reste combien d'espace libre sur au moment du crash / ?

As-tu installé mrtg ? Cela te permettrait de voir à quelques minutes près.

Pour moi c'est mysql. Pense aussi à vérifier ta base de données et à mettre un index sur tous les champs que tu trouves après 'WHERE..." dans tes scripts

Pour vérifier utilise au choix myisamchk ou mysqlcheck. Le premier nécessite l'arrêt de mysql alors que le second en a besoin.

Le plus simple est de lancer:

mysqlcheck -r --all-databases

Dan

[Amibien]

Tu as raison, je m'en vais de ce pas m'occuper de ces fichiers temporaires.

Pour moi c'est mysql. Pense aussi à vérifier ta base de données et à mettre un index sur tous les champs que tu trouves après 'WHERE..." dans tes scripts

Tu peux m'en dire un peu plus sur cet index

A quoi sert-il, comment le mettre, ou lien vers une éventuelle doc à ce sujet ?

Merci encore pour ton aide.

Pour l'espace au moment des crash, j'ai juste remarqué que la ram ne semblait pas saturée... je vais essayer d'obtenir plus d'info la dessus.

[Dan]

Pour l'espace au moment des crash, j'ai juste remarqué que la ram ne semblait pas saturée... je vais essayer d'obtenir plus d'info la dessus.

Normal si c'est le TMPDIR de mysql qui se remplit...

Pour créer un index, quand on ne maîtrise pas mysql, il suffit d'ouvrir phpMyAdmin et cliquer sur l'icône index sur la ligne du champ

[Amibien]

Snif, je reviens vers vous car même après avoir fait la modif dans le fichier mysql, les plantages continuent...

Toujours pareil, ftp ok, apache ok, mails ok, mais mysql et ovhm HS...

L'intervention du technicien a donné ca :

Voici le détail de l'intervention réalisée:

2006-04-13 17:41:43 - Votre serveur ne ping plus

2006-04-13 17:52:53 - rachid prends en charge l'intervention

2006-04-13 18:13:15 - rachid a fait: Downgrade hardware

le serveur etait sur ecran noir.

apres reboot ping ok,

amelioration du refroidissement cpu.

A titre informatif, le temps de resolution de l'incident a ete de:

31 minutes 32 secondes

C'est la 1ère fois d'ailleurs que j'entends parlé de downgrade... ils m'ont mis un pentium 100 en CPU ?

J'ai profité de tous ces plantages pour ajouter également quelques infos mrtg :

*ttp://ns31893.ovh.net/mrtg/

*ttp://ns31893.ovh.net/mrtg/qmail

J'ai remarqué au moment du plantage une utilisation CPU à 90-100%, et utilisation du swap

Mais tout çà me semble la plupart du temps bien peu surchargé...

En espérant que vous aurez d'autres pistes de recherches

[snakes]

J'ai le meme problème depuis un moment et depuis ce weekend ca s'aggrave.

J'ai les memes erreurs kernel.

Le SVD est un Start300G donc 2400MHz et 512Mo de RAM.

Quand ca plante, ssh, httpd et mysql ne répondent plus.

Si je suis deja sur ssh alors ca lagg a fond.

[Amibien]

bon rebelotte plantage hier soir... ovhm hs, apache hs, j'ai pu accéder uniquement au ssh et faire un reboot

J'ai effectué un check disk aujourd'hui, rien d'anormal...

Quelques pics mrtg cependant (cf url de mon précédent post)

Je viens de tomber en revanche sur une doc intéressante :

configuration du serveur:

les serveurs qui sortent d'ovh sont testés 48H sur nos bancs d'essais.

pendant ces tests on bride les serveurs web en nombre de connexion

simultané qui est souvent en fonction de la RAM disponible sur le

serveurs. Ce bridage permet d'avoir un serveur stable même pendant

les attaques flood ou des surchargés su serveur. Par contre si vos

visiteurs sont plus nombreaux que le nombre de connexion max alors

_ça rame_ . En gros ils attendent qu'une connexion se libere.

Vous avez aussi compris qu'il est donc à éviter le download massives

des fichiers via le web vu que le telechagement prend souvent

plusieurs minutes. Si vous avez 100 connexions ouverts (128RAM) et

vous avez 1 clients par sec et ça dure plus que 100 sec son telechargement

vous saturez le serveur web et ça rame alors que le serveur a du CPU

libre. Il faut utiliser le ftp anonymous pour ce genre des choses

lequel est possible en plus brider à nombre de connexions simultanés

et la bande passante par connexion. Bref.

l'option dans httpd.conf la variable qui fixe ceci est

MaxClients 30

permet de choisir le nombre de connexion en simu. Ne debridez pas cette

valeur si vous ne faites pas l'augmentation de la RAM sinon votre

serveur swappera et tombera en 2sec. Il faudra le rebooter EN HARD

et un check des disques s'imposera (entre 20-90minutes). Donc

si votre nombre de connexion est au max, il faut augmenter la RAM

et monter le nombre de MaxClients. Le problème est qu'après l'augmentation

de la RAM, nous on ne fait plus des tests en charge et on ne peut

que se baser sur l'experiance pour fixer le MaxClients, alors tout

depend du CPU/IDE/SCSI/RAID/type des connexion etc. voilà voilà.

Je vérifie ma conf et je contaste que mes paramètres sont les suivants :

MaxKeepAliveRequests 100

KeepAliveTimeout 15

MinSpareServers 10

MaxSpareServers 20

StartServers 15

MaxClients 150

MaxRequestsPerChild 60

Pourquoi ce paramètre de conf ne semble pas bridé (je possède 512 mo de ram ce qui ne me semble pas enorme).

Dois-je diminuer sa valeur et si oui à cb ?

Quand est-il des autres paramètres, sont -ils bien paramétrés ?

Modifié 1 Mai 2006 par Amibien

[Kwiz]

Si MaxClients et proportionnel à la Ram, alors pour 512Mo MaxClients devrait être à 120.

Kwiz

[Dan]

Le MaxClients à 150 est la config de base chez OVH. Cela suffit pour un serveur avec 512MB de RAM. Tu pourrais le baisser à 100, mais à mon avis ce n'est pas cela qui fait planter le serveur.

Une limitation: ne dépasse pas 256. Au delà il faut recompiler Apache. Mais de toutes manières tu n'as pas assez de RAM pour cette valeur.

Quantité de sites fonctionnent parfaitement avec ces valeurs de base.