Version complète: sur le forum Webmaster Hub : Mon serveur est HS :/
Webmaster Hub > Création et exploitation de Sites Internet > Les fondations d'un site
Occi
samedi 29 mars 2008 à 18:34
Bonjour,

j'ai mon serveur qui a planté, je me demande si ça ne vient pas du dossier /home car dans "état du serveur" sur le manager OVH je vois :

Utilisation disque dur
Utilisation(s) pour [ / ] : 55 %
Utilisation(s) pour [ /home ] : 100 %

J'ai une base de données qui crashée et impossible de la réparer, peut être ça vient de là non ?

Je reboot (en hard) le serveur mais ça n'arrange pas le problème.

Quand je vais dans Plesk je vois l'insulte :

CITATION
ERROR: Unable to connect to database: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (111) 0: /usr/local/psa/admin/auto_prepend/auth.php3:67 psaerror(string "Unable to connect to database: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (111)")


La commande shell "top" me renvoit ceci:

CITATION
top - 18:50:40 up 10 min, 1 user, load average: 1.02, 0.89, 0.48
Tasks: 78 total, 1 running, 77 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0% user, 10.2% system, 0.0% nice, 89.8% idle
Mem: 1014612k total, 167628k used, 846984k free, 20848k buffers
Swap: 1044208k total, 0k used, 1044208k free, 50984k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11 root 8 -20 0 0 0 S 9.0 0.0 0:32.11 raid1d
12 root 19 19 0 0 0 D 2.0 0.0 0:21.69 raid1syncd
4282 root 10 0 904 904 728 R 0.3 0.1 0:00.09 top
1 root 9 0 484 484 416 S 0.0 0.0 0:03.46 init
2 root 9 0 0 0 0 S 0.0 0.0 0:00.00 keventd
3 root 19 19 0 0 0 S 0.0 0.0 0:00.05 ksoftirqd_CPU0
4 root 19 19 0 0 0 S 0.0 0.0 0:02.07 ksoftirqd_CPU1
5 root 9 0 0 0 0 S 0.0 0.0 0:00.00 kswapd
6 root 9 0 0 0 0 S 0.0 0.0 0:00.00 bdflush
7 root 9 0 0 0 0 S 0.0 0.0 0:01.01 kupdated
8 root 9 0 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_0
9 root 9 0 0 0 0 S 0.0 0.0 0:00.00 scsi_eh_1
10 root -1 -20 0 0 0 S 0.0 0.0 0:00.00 mdrecoveryd
13 root -1 -20 0 0 0 S 0.0 0.0 0:00.00 raid1d
14 root -1 -20 0 0 0 S 0.0 0.0 0:00.00 raid1syncd
15 root 9 0 0 0 0 S 0.0 0.0 0:00.19 kjournald
1079 root 9 0 0 0 0 S 0.0 0.0 0:00.24 kjournald
5330 root 9 0 560 560 480 S 0.0 0.1 0:00.04 syslogd
5788 root 9 0 436 436 380 S 0.0 0.0 0:00.00 klogd
23723 root 9 0 440 440 380 S 0.0 0.0 0:00.01 irqbalance
25411 rpc 9 0 572 572 484 S 0.0 0.1 0:00.00 portmap
12799 rpcuser 9 0 720 720 628 S 0.0 0.1 0:00.00 rpc.statd
3914 root 9 0 2104 2104 1632 S 0.0 0.2 0:00.02 cupsd
16778 named 9 0 3380 3380 2164 S 0.0 0.3 0:00.01 named
11230 named 9 0 3380 3380 2164 S 0.0 0.3 0:00.00 named
28661 named 9 0 3380 3380 2164 S 0.0 0.3 0:00.14 named
28428 named 9 0 3380 3380 2164 S 0.0 0.3 0:00.00 named
7638 named 9 0 3380 3380 2164 S 0.0 0.3 0:00.02 named
26891 root 9 0 1452 1452 1348 S 0.0 0.1 0:00.03 sshd
11593 root 9 0 888 888 752 S 0.0 0.1 0:00.00 xinetd
1385 root 9 0 876 876 764 S 0.0 0.1 0:00.00 couriertcpd
21809 root 9 0 444 444 340 S 0.0 0.0 0:00.00 courierlogger
22013 root 9 0 876 876 764 S 0.0 0.1 0:00.00 couriertcpd
19545 root 9 0 440 440 340 S 0.0 0.0 0:00.00 courierlogger
4357 root 9 0 876 876 764 S 0.0 0.1 0:00.00 couriertcpd
9511 root 9 0 440 440 340 S 0.0 0.0 0:00.00 courierlogger
29560 root 9 0 876 876 764 S 0.0 0.1 0:00.00 couriertcpd
18260 root 9 0 436 436 340 S 0.0 0.0 0:00.00 courierlogger
6737 qmails 9 0 440 440 364 S 0.0 0.0 0:00.00 qmail-send
25547 qmaill 9 0 424 424 368 S 0.0 0.0 0:00.01 splogger
31626 root 9 0 324 324 248 S 0.0 0.0 0:00.01 qmail-lspawn
22807 qmailr 8 0 356 356 276 S 0.0 0.0 0:00.02 qmail-rspawn


Vous voyez quelque chose qui cloche ?

Merci d'avance pour votre aide, je ne vois pas quoi faire sad.gif
Kioob
samedi 29 mars 2008 à 18:51
Bonjour,

une partition saturée à 100%, ce n'est jamais bon effectivement. Et si les données MySQL y sont stockées, c'est évident que c'est la cause des corruptions de la base.

Le problème serait plutôt de trouver ce qui sature complètement cette partition : fichiers temporaires de mod_deflate (dans /tmp en théorie), fichiers de logs Apache (avec Plesk dans /home/vhost/SITE/logs/ je crois), fichiers de sessions non effacés (aucune idée du lieu de stockage avec Plesk). Le tout agrémenté d'un partitionnement "à la con" made in OVH, c'est pas gagné biggrin.gif
Occi
samedi 29 mars 2008 à 19:06
Merci pour ta réponse.

J'ai viré des logs pour libérer de la place mais rien y fais.
Impossible de relancer Mysql via Shell ni après reboot.
Pour les sessions il y en pas.

Une idée stp ? sad.gif
Kioob
samedi 29 mars 2008 à 19:15
Et bien si tu n'as pas les compétences pour trouver ce qui sature cet espace disque, le mieux est de passer par les services de quelqu'un qui les a (Dan par exemple).

Après, intervention en urgence un week end, faut voir biggrin.gif Dans tous les cas : ton "hébergeur" n'est pas sensé avoir un support ?
Occi
samedi 29 mars 2008 à 19:22
OVH un support ? shutup.gif
Je vais prendre contact mais bon, dans le passé je n'ai pas été spécialement ébloui par la réactivité et la pertinence pour la résolution de problème hélas.
Kioob
samedi 29 mars 2008 à 19:25
N'est ce pas risqué dans ce cas de prendre une machine chez ce type de fournisseur ? tongue.gif
Dan
samedi 29 mars 2008 à 19:28
Malheureusement je n'ai aucune expérience en cette usine à gaz nommée Plesk.
Je n'aurais pas donné d'autre réponse que Kioob...

As-tu par hasard des scripts qui tournent avec cron et enregistrent un log quelque part ?
Dans le doute, j'arrêterais mysql et apache, et essaierais de lancer un logrotate.

Tu peux aussi t'assurer que les logs des jours précédents ont bien été compressés.

Qu'as-tu comme message en lançant mysql ? Que donne un "df" ?
Tu peux lancer (avec mysql arrêté) un
"myisamckk --force --recover *.MYI" en te mettant dans le répertoire de chaque base.

Dan
samedi 29 mars 2008 à 19:31
CITATION(Kioob @ samedi 29 mars 2008 à 19:25) *
N'est ce pas risqué dans ce cas de prendre une machine chez ce type de fournisseur ? tongue.gif

OVH s'adresse plus, du moins en ce qui concerne les serveurs dédiés, à des personnes qui maîtrisent un minimum l'administration du serveur.
Comme tu disais précédemment, si on n'a pas les bases nécessaires, il faut à ce moment là confier l'infogérance à quelqu'un qui "sait faire".

Je ne prêche pas pour ma chapelle, vu que je ne fais pas d'infogérance sur les serveurs avec Plesk. tongue.gif
Kioob
samedi 29 mars 2008 à 19:43
Je crois que personne ne serait assez fou pour faire de l'infogérance sur du Plesk wink.gif. J'ai eu la "chance" de travailler avec des machines sous Plesk, et sait donc à peu près où sont stockés ces fichus fichiers... et encore.

En tous cas là c'était un joli fichier de log Apache qui faisait quelques 60Go sur une partition de 70Go. biggrin.gif
Occi
samedi 29 mars 2008 à 20:07
Merci Dan pour ta réponse, c'est bon c'est arrangé... ouf

Kioob a arrangé le problème en moins de temps qui ne m'a fallu pour répondre au post. En fait c'était un fichier log d'erreur de 60G, qui s'est mis à dérailler à partir d'hier apparement :/

CITATION
Tu peux lancer (avec mysql arrêté) un
"myisamckk --force --recover *.MYI" en te mettant dans le répertoire de chaque base.

Que fait cette commande ?

Pour répondre concernant mon choix de fournisseur, bein en fait OVH a du bon matériel et de bon tarif, voila pourquoi ce choix.

D'ailleur je vais prendre d'ici quelques jours un service d'infogérance (sous Débian whistling.gif ) , c'est trop la galère le faire sois même avec peu de base...
Dan
dimanche 30 mars 2008 à 11:09
La commande myisamchk (qui ne peut tourner que lorsque mysql est arrêté) permet de vérifier tes tables, corriger les erreurs, recréer les index, etc.

Je te suggère de lire cette page pour avoir une vue plus complète: http://dev.mysql.com/doc/refman/5.0/fr/tab...aintenance.html


Occi
dimanche 30 mars 2008 à 13:25
D'accord c'est bon à savoir, merci pour le lien je regarde ça smile.gif
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.