Aller au contenu

Sujets conseillés

Posté (modifié)

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 :

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:

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 :(

Modifié par Occi
Posté

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é :D

Posté (modifié)

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 ? :(

Modifié par Occi
Posté

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 :D Dans tous les cas : ton "hébergeur" n'est pas sensé avoir un support ?

Posté

OVH un support ? :shutup:

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.

Posté

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.

Posté
N'est ce pas risqué dans ce cas de prendre une machine chez ce type de fournisseur ? :P

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. :P

Posté

Je crois que personne ne serait assez fou pour faire de l'infogérance sur du Plesk ;). 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. :D

Posté (modifié)

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 :/

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: ) , c'est trop la galère le faire sois même avec peu de base...

Modifié par Occi
Posté

D'accord c'est bon à savoir, merci pour le lien je regarde ça :)

Veuillez vous connecter pour commenter

Vous pourrez laisser un commentaire après vous êtes connecté.



Connectez-vous maintenant
×
×
  • Créer...