serveur surchargé à près de 200.00 de load avg

[i-services]

salut,

j'ai installé mon nouveau serveur et il n'y a meme pas encore la moitié de mon trafic dessus (load balancing) qu'il sucharge à près de 200.00. J'ai été obligé de le rebooter en hard

maintenant la charge est de 0.05 mais comment voir ce qui a cause cette surcharge ? dans le répertoire /tmp je vois plein de fichier .wrk

merci

Olivier

[i-services]

dans le fichier error_log d'apache je vois ceci juste avant la surcharge

mod_gzip: TRANSMIT_ERROR:ISMEM:104
mod_gzip: TRANSMIT_ERROR:ISMEM:104
mod_gzip: TRANSMIT_ERROR:ISMEM:104
mod_gzip: TRANSMIT_ERROR:ISMEM:104

[Elgi]

i-services écrivait :
dans le fichier error_log d'apache je vois ceci juste avant la surcharge

mod_gzip: TRANSMIT_ERROR:ISMEM:104
mod_gzip: TRANSMIT_ERROR:ISMEM:104
mod_gzip: TRANSMIT_ERROR:ISMEM:104
mod_gzip: TRANSMIT_ERROR:ISMEM:104

mod_gzip qui fonctionne mal, il me semble deux solutions possibles :
- commander mod_gzip dans le httpd.conf,
- recompilez php avec mod_gzip correctement.

[Elgi]

Elgi écrivait :
mod_gzip qui fonctionne mal, il me semble deux solutions possibles :
- commentez mod_gzip dans le httpd.conf,
- recompilez php avec mod_gzip correctement.

[i-services]

recompilez php avec mod_gzip correctement

tu peux m'en dire plus ? qu'est-ce qui est mal compilé à php ? je n'y ai pas touché c'est un nouveau serveur

[Elgi]

i-services écrivait :
recompilez php avec mod_gzip correctement

tu peux m'en dire plus ? qu'est-ce qui est mal compilé à php ? je n'y ai pas touché c'est un nouveau serveur

Un bout de la manip pour l'installation de mod_gzip, tu peux verifie si tes sources php ont bien le fichier mod_gzip.c dans le répertoire spécifié ci-dessous :

gunzip -f src/mod_gzip.c.gz
cd apache_1.3.x
cp ../mod_gzip.c src/modules/extra/
./configure \
--prefix=/usr/local/apache

[i-services]

et il est utile mod_gzip ? si je le désactive les performances s'en resentiront ?

c'est uniquement pour compresser les pages et les afficher plus vite ?

[Elgi]

i-services écrivait :
et il est utile mod_gzip ? si je le désactive les performances s'en resentiront ?

c'est uniquement pour compresser les pages et les afficher plus vite ?

je dirais oui c'est utile puisque ca comprimme les pages, alors ca t'economise de la bande passante et l'envoie dure moins longtemps, occupe donc moins de temps les process charge de faire tout ce ptit travail.

mais, il est pas vital !

dans un premier temps tu devrais pouvoir commenter mod_gzip dans ton httpd.conf, relancer apache et voir si c'est erreur persiste ou non.

[TranSGeniK]

mod_gzip: TRANSMIT_ERROR:ISMEM:104

Cette erreur est due à l'annulation d'un transfert, donc c'est normal (le client qui arrete le transfer d'une page par example), aucun rapport avec ta charge.

Regarde dans ton tmp/
Si tu as des fichiers .wrk vraiment balaises genre 400Mo c'est qu'il y a eu une couille avec mod_gzip.
Dans ce cas supprime les fichiers .wrk trop gros, et redemarre Apache.

Ce genre de couille est rare. J'en ai eu peut être 2 en 1 an.

Mais des mod_gzip: TRANSMIT_ERROR:ISMEM:104 j'en ai plein dans mes fichiers d'erreur comme tout le monde.

[i-services]

pourtant dans mes logs je vois vers 22h

TRANSMIT_ERROR:ISMEM:104
TRANSMIT_ERROR:ISMEM:104
TRANSMIT_ERROR:ISMEM:104
TRANSMIT_ERROR:ISMEM:104

puis plus rien comme erreur dans les logs jusque 23h30 (quand j'ai rebouté)

j'avais une centaine de fichier .wrk mais la plupart de 0ko et les autres d'une centaine de ko, maximum 1Mo

[OVH]

Si vous avez des machines sur differentes classes d'ip vous ne pouvez pas utiliser NFS dans les bonne conditions. Il faut créer un vlan privé et mettre toutes les machines sur le même switch et la même classe d'ip. Vous ne pourrez pas juste prendre une nouvelle machine sur n'importe laquelle classe d'ip et quelque soit le lieu d'hébergement de la machine, car NFS ne voudra pas fonctionner correctement.

Les surchages que vous avez sont probablement dû au fait que le clent NFS a des coupures vers le serveur NFS. Si c'est le cas vous devez avoir des messages dans dmesg suivants:
nfs: server XXXX not responding, still trying
nfs: server XXXX OK

Dans tous les cas, vous ne trouverez pas d'aide sur le forum. Ce sont des problèmes complexes où il n'y a pas des reponses toutes faites ou des reponses oui/non. Le lecteur du forum ne comprendra pas vos problèmes qu'à travers et tout ce que vous allez reussir à avoir comme reponse c'est "dédié c'est complexe. on n'y comprend rien".

Nous vous conseilons contacter notre support commercial avec la liste de vos serveurs/ip afin qu'on puisse vous trouver une solution aux problèmes.

[i-services]

mes serveurs sont sur la meme classe d'IP et le meme switch (213.186.39.x)

le problème recommence ce matin :( et la je n'ai qu'un seul fichier .wrk de 0 octets et dans les error log j'ai encore une ligne avec mod_gzip un peu avant la surcharge

le problème se produit chaque fois après plusieurs heures ou tout fonctionne parfaitement bien

[i-services]

si qqn d'OVH pouvait m'aider ce serait bien :/ on pourrait ensuite le mettre dans le guide des machines surchargées, d'autres en profiteraient

Je rappelle les faits :

- Il s'agit d'un nouveau serveur avec peu de connexions apache car les dns ne sont pas encore totalement propagés

- Le serveur est sur la meme classe d'IP et le meme switch que mes 2 autres serveurs qui eux n'ont aucun problème

- Toutes les x heures la charge monte brutalement à plus de 150.00 et la machine plante, obligé de rebooter en hard via le manager

- La première fois, j'ai eu plein de .wrk dans /tmp, la fois suivante un seul de 0 octets, donc ça vient sans doute pas de la. Mais à chaque fois j'ai vu une ligne dans erreur log avec mod_gzip: TRANSMIT_ERROR:ISMEM:104

Voila, je peux rien dire de plus, les logs ne m'apprennent rien d'autre et /var/log/message et dmesg sont effacés après le reboot :(

merci d'avance, j'ai contacté le support mais à mon avis ils vont me rediriger vers le forum

Olivier

[i-services]

ça vient de recommencer :( je me suis absenté une minute quand la charge était de 0.05 (depuis une heure), quand je suis revenu pluis rien ne répondait

mais cette fois pas d'erreur de mod_gzip donc on peut écarter cette cause

tant pis je vais modifier mes dns pour retirer le load balancing car mes visiteurs, membres et clients ne vont pas aprécier que je reboot le serveur toutes les heures.

J'espère qu'OVH voudra bien se pencher sur le problème car sinon ce serveur aura été loué pour rien car je ne compte pas l'utiliser dans de telles conditions :(

en attendant je vais surveiller le top pour pas rater le prochain plantage et je vous mettrai une capture d'écran

[i-services]

est-ce que ça peut venir d'une mauvais configuration de resolf.conf ?

http://forum.ovh.com/showthread.php?s=&threadid=570

est-ce que je dois mettre l'IP de mon autre serveur, sur lequel mes zones primaires ont été créées ?

[i-services]

et voila ça recommence, voici les capture, regardez comme la charge monte brutalement (comparez le load average sur 1 et 5 minutes)

http://dev.i-services.net/temp/ecran1.png

http://dev.i-services.net/temp/ecran2.png

10 secondes plus tard c'était sur 150 et et du rebooter

[i-services]

-

[i-services]

tiens que représentent les processus D sur la deuxième image ? Est-ce que ce ne sont pas eux qui font tout planter ?

[PO, maitre PHP]

300 process qui tournent c bcp non ? pt etre ton apache n'est pas assez restrictif, il "spawn" trop de "child" (j'ai la flemme de trouve l'equivalent francais :) )

[i-services]

Le problème semble réglé, cela venait d'un bug dans le kernel avec les CPU en hyperthreading.

pour ceux qui ont des problèmes de plantage de leur serveur, mettez dans /etc/lilo.conf append="noapic" en-dessous de root=/dev/sda1

[DW1]

i-services écrivait :
Le problème semble réglé, cela venait d'un bug dans le kernel avec les CPU en hyperthreading.

pour ceux qui ont des problèmes de plantage de leur serveur, mettez dans /etc/lilo.conf append="noapic" en-dessous de root=/dev/sda1

il m'arrive quotidiennement d'avoir un bpm similaire de plantage
MRTG (http://ns3306.ovh.net/mrtg/mrtg-sys/ns3306.ovh.net_charge.html)

ma question est : comment on fait pour savoir si le pbm peut venir de kernel et du cpu en hyperthreading, je voudrais pas modifier lolo.conf pour rien.
il faut redemmarer quels services après la modif ?

Merci