OVH Community, votre nouvel espace communautaire.

SuperPlan, plantage au heures de pointes


multinetworks
28/02/2004, 23h18
Je vais vérifier, merci de tes conseils.

ps
28/02/2004, 23h16
ok , ça devait sans doute vu la taille être des fichiers delogs renommés ou générés par tes crons php que tu avais.
Verifie d'ailleurs que tu n'ai pas un cron qui traîne et qui génèrerai ces types de fichiers.

multinetworks
28/02/2004, 23h10
Dans ce fichier, il y a des erreurs php de type Warning suite à un fichier qui n'a pas pu etre executé. Bref, de la connerie, j'ai viré car en plus ca date de Aout 2003 donc voilà quoi.

ps
28/02/2004, 21h25
bon ok, t'as réussi a localiser ton pb.
Sur ton serveur t'as 2 partitions
une partition /
une partition /home
donc ton repertoire /tmp est dans la partition système soit la partition / qui était utilisée à 99% d'ou les problèmes d'écriture que tu as rencontré

tes fichiers index.php c pas normal qu'ils aient une taille aussi grande. Ce sont des fichiers php pour le web, ils ne doivent pas arriver à une telle taille surtout que ce n'est que du texte a priori.

T'as qu'a faire la commande suivante:

more /lechemin/vers/ton/fichier et regarde ce qu'il ya dedans

si tu ne connais pas le contenu, poste sur le forum

multinetworks
28/02/2004, 19h04
J'ai réussi a faire plus simple, dans /root/, j'avais des fichiers de quand j'ai installé des logiciels sur le serveur, j'ai deplacé ces archives .tar.gz vers /home/archives/

Quand j'ai tapé la commande "ls -lh --sort=size|head" qui donne les 10 plus gros fichiers, j'ai obtenu ceci : total 460M
-rw-r--r-- 1 root root 217M aoû 15 2003 index.php
-rw-r--r-- 1 root root 214M aoû 15 2003 index.php.1
-rw-r--r-- 1 root root 9.8M jui 17 2003 apache_1.3.28.tar
-rw-r--r-- 1 root root 4.3M jan 26 2003 maildrop-1.5.2.tar
-rw-r--r-- 1 root root 4.3M jui 22 2003 php-4.3.2.tar.gz
-rw-r--r-- 1 root root 2.7M jui 18 2003 mod_ssl-2.8.15-1.3.28.tar
-rw-r--r-- 1 root root 2.3M oct 24 18:50 apache_1.3.29.tar.gz
-rw-r--r-- 1 root root 983k déc 6 17:59 bzImage-2.4.23-piv
-rw-r--r-- 1 root root 983k déc 6 18:02 bzImage-2.4.23-piv.1

Désormais quand je tape la commande "df -h", j'obtiens ceci :
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda1 2016016 1420916 492688 75% /
/dev/hda2 36977736 4403296 30696040 13% /home
none 63028 0 63028 0% /dev/shm

Déjà mieux que tout à l'heure.


Je me demande bien ce que c'est que ces 2 fichier index qui pèse comme meme 200 Mo. Vous avez cela vous aussi sur votre serveur dans /root/ ?

multinetworks
28/02/2004, 18h35
J'obtient ceci :
Filesystem Size Used Avail Use% Mounted on
/dev/hda1 1.9G 1.8G 30M 99% /
/dev/hda2 35G 3.8G 29G 12% /home
none 62M 0 61M 0% /dev/shm

En effet, ma partition hda1 es très utilisée, il faudrait l'agrandir et retrecir la partition hda2.

ps
28/02/2004, 18h23
est ce que ton /tmp est monté sur une partition à part?

si oui tu dois le voir en faisant la commande
df -h

ça te donnera tous les montages disques. Si t'en a un qui s'appelle /tmp t'aura l'a taille

ex:

df -h

Filesystem Size Used Avail Use% Mounted on
/dev/hda1 8.4G 2.4G 5.6G 30% /
/dev/hda2 20G 33M 19G 1% /backup
/dev/hda5 8.4G 4.0G 4.0G 51% /home

là tu as clairement 3 partitions disques, une /, une /home et une /backup
Tu as pour chacune la taille, la quantité utilisée, et la quantité libre

multinetworks
28/02/2004, 18h05
Désormais, ça ne plante plus. C'est juste Apache qui peut plus travailler car il n'a plus de place dans /tmp/

Pourtant, chaque heure, le repertoire est vidé.

Est ce que qqn aurait une commande pour voir combien de place est alloué à /tmp/ et si ce n'est pas assez un How-To pour l'angrandir...

multinetworks
28/02/2004, 12h53
ok, je viens de supprimer qqes cron assez douteux...
Je vais voir ce que ca donne

Merci de vos réponses

OVH
28/02/2004, 09h41
Sur vos graphes mrtg on peut voir qu'à 3h du matin hier un process s'est lancé qui a pris toute la puissance CPU restante:
http://stats.multinetworks.net/mrtg-...h.net_cpu.html
La charge de la machine a évolué dans la journée jusqu'à plantage.

Vous devriez regarder votre crontab pour savoir exactement de quel process il s'agit. Comme ça a commencé à 3h exactement on peut penser au calcul des logs ou d'autres process lourds. Ceci peut être aussi un script php qui a planté. Dans tous les cas, l'origine du problème est bien un process qui pris toutes les resources CPU.

Au niveau de la RAM, tout est correct:
http://stats.multinetworks.net/mrtg-...h.net_mem.html

TranSGeniK
28/02/2004, 00h41
Ça sent le Super Plan + tout ça

multinetworks
27/02/2004, 22h40
le repertoire /tmp/ est vidé chaque heure et le plus gros fichier trouvé est 4 Mo.

Pour ce qui est de ça, j'ai suivit le guide ovh :
nombre de slot apache de ns3978.ovh.net n'a pas l'air bien configuré.
http://guides.ovh.com/InstallMRTGSys/
Toujours important de savoir si y a pas de problème de saturation apache par exemple.


En ce qui concerne la commande top, rien d'anormal.

Pour les logs de la journée, on remarque les plantages :
http://stats.multinetworks.net/webal...ge_200402.html

TranSGeniK
27/02/2004, 21h03
espace disponible sur / et /home de ns3978.ovh.net en %

Ton / est saturé Mod_gzip ne peut donc plus travailler (par exemple).
Regarde dans /tmp si tu n'as pas des fichiers .wrk un peu trop balaises genre 400 Mo, si c'est le cas supprime les.

nombre de slot apache de ns3978.ovh.net n'a pas l'air bien configuré.
http://guides.ovh.com/InstallMRTGSys/
Toujours important de savoir si y a pas de problème de saturation apache par exemple.

Ça donne quoi au niveau du swap (commande top sous ssh)?
Biensur regarde ce que donne les logs d'erreur.

multinetworks
27/02/2004, 20h43
Bonsoir,
Chaque soir, mon serveur un SuperPlan plante chaque soir aux heures de pointe.

Voici les courbes obesrvés MRTG-Sys : http://stats.multinetworks.net/mrtg-sys/

Dans le guide, ovh il est marqué que si le CPU dépasse 10 %, et bien il faut changer de serveur. Moi mes plantages sont du à un manque de RAM.

Doit-je migrer vers un SuperPlan +, à votre avis ?

Merci de vos conseils