Webmaster Hub > Plantages serveur incessants sur un dédié OVH

Version complète: sur le forum Webmaster Hub : Plantages serveur incessants sur un dédié OVH

Webmaster Hub > Informatique & Internet > PC-Gyver

Amibien

samedi 1 avril 2006 à 18:18

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)

CITATION

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

CITATION

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.

CITATION

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

CITATION

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

CITATION

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

CITATION

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 :

CITATION

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

Dan

samedi 1 avril 2006 à 18:34

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

samedi 1 avril 2006 à 18:44

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 traffic 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

samedi 1 avril 2006 à 19:38

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:

CODE

mysqlcheck -r --all-databases

Dan

Amibien

lundi 3 avril 2006 à 14:27

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

CITATION

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

mardi 4 avril 2006 à 10:52

CITATION(Amibien @ lundi 03 avril 2006, 15h27)

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

jeudi 20 avril 2006 à 18:12

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 :

CITATION

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

lundi 24 avril 2006 à 11:54

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

lundi 1 mai 2006 à 15:08

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 :

CITATION

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 :

CITATION

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 ?

Kwiz

lundi 1 mai 2006 à 18:11

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

Kwiz

Dan

lundi 1 mai 2006 à 18:31

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.

Ceci est une version "bas débit" de notre forum. Pour voir la version complète avec plus d'information, la mise en page et les images, veuillez cliquer ici.