Forum Linux.général Oû sont passé mes kilos ?

Posté par  (site web personnel) .
Étiquettes : aucune
0
11
mai
2010
Salut,

Derrière ce titre ridicule se cache un réèl problème que j'ai depuis quelques mois sur un serveur dédié chez un hébergeur en 3 lettres.

La partition /var souffre en effet de manque de place, je décide donc d'aller faire du ménage mais pas moyen de trouver ce qui prend de la place, la commande df me renvoie que sur les 6.8Go de la partition, 6.2Go serait utilisé et pas moyen de savoir oû.

Un df -h me renvoit ceci, j'ai caché ce qui ne nous intéresse pas ici :

Filesystem Size Used Avail Use% Mounted on
[...]
/dev/hda6 6.8G 6.2G 201M 97% /var
[...]


Or, un du -hs dans /var me renvoie ceci :

5.1M backups
21M cache
146M lib
4.0K local
12K lock
74M log
16K lost+found
4.0K mail
4.0K opt
204K run
1.7M spool
16K tmp
24M www


Soit, quelques 271Mo utilisés, ça fait une sacré différence...

J'ai tenté un mount -o remount /var mais rien n'y fait, j'ai toujours ce gouffre entre les 2 commandes et toujours ce manque de place réel...
Il y a quelques mois, j'avais trouvé lors de recherches sur le sujet un document expliquant que c'était le système de fichiers (ext3) qui se gardait un peu de place au cas oû mais de là à garder autant, ça ne peut être ça, dans le doute, j'avais testé la soluce, j'ai réussi à gratter un tout petit peu mais rien de significatif.

Quelqu'un dans la salle aurait une piste à me donner ?

  • # Fichiers effacés, handles ouverts

    Posté par  (site web personnel) . Évalué à 4.

    N'aurais-tu pas effacé l'un ou l'autre gros fichier ? Je pense en particulier aux logs binaires de mysql.

    Si une application (mysql ?) les maintenait ouverts pendant que tu les supprimais, ils sont toujours sur le disque, même si tu ne les vois plus. Ils ne seront réellement désalloués que lorsque mysql aura libéré le handle. Redémarre le service (mysql ?) et vois si la place est revenue.

  • # Monsieur Propre

    Posté par  . Évalué à 2.

    Etape 1: redémarrer la machine. Ben oui, certains prétendent que c'est mal, mais ça ne prends que 5 minutes pour écarter beaucoup d'hypothèses.

    Etape 2: si aucune amélioration, il faut lancer un fsck (sans réparer). Si il te sort une grosse liste d'erreur, tu as trouvé ton problème. Sauvegarde, puis réinstallation de la machine. Ou juste sauvegarde puis recréation de ton répertoire, c'est selon les goûts, le désir de se faire des frissons, toussa.

    • [^] # Re: Monsieur Propre

      Posté par  (site web personnel) . Évalué à 3.

      Bon, c'est un serveur de prod distant avec quelques sites qui tournent dessus donc bon, le redémarrage n'est pas un choix qui se prend comme ça, cela dit, tu as raison, le redémarrage aide parfois, mais il y a quelques temps, le serveur à du être rebooté pour une autre raison et ça n'a rien changé à ce problème.

      Je viens de tenter un fsck qui me faisait assez peur mais ça s'est bien passé ormis le démontage du var mais lsof m'a aidé.
      Il y avait pas mal d'erreur mais j'ai récupéré mes kilos ;)

      Le serveur va mieux, je vais mieux, merci ;)

      • [^] # Re: Monsieur Propre

        Posté par  . Évalué à 1.

        Bonjour,

        C'était peut-etre du au trop grand nombre de fichiers (entendre petits fichiers) sur le disque. Un 'df' te dit qu'il reste de l'espace disque mais tous les blocs sont en réalité utilisés. Un tel phénomène sur la partition /var ne serait pas étonnant, avec tous les fichiers journaux qui y sont stockés.

        Le petit écart entre 6.2 et 6.8 me parait explicable par cet argument... ou pas.

        • [^] # Re: Monsieur Propre

          Posté par  (site web personnel) . Évalué à 1.

          Le petit écart entre 6.2 et 6.8 me parait explicable par cet argument... ou pas.

          L'écart n'était pas de 0.6Go mais de 6Go... ;)

    • [^] # Re: Monsieur Propre

      Posté par  . Évalué à 5.

      redémarrer la machine

      tss tss tss réflex de Windowsien ça ... :D
      si ça se passe mieux après le redémarrage, le problème n'est pas identifié, et du coup, si ça se reproduit, on en est toujours au même point.

  • # dumpe2fs /dev/hda6

    Posté par  . Évalué à 2.

    Pour la différence entre la taille de la partition != l'espace disque libre + l'espace disque utilisé : Il s'agit des "reserved blocks" : sur un fs en ext2 (ou ext3) tu auras toujours des blocks reservés. Tu peux voir leur comptage actuel avec dumpe2fs et en changer le nombre avec tune2fs.

    Ensuite tu peux toujours activer la compression des log si tu utilise logrotate (en ajoutant "compress" dans les fichiers de conf de celui-ci (/etc/logrotate.conf ou dans /etc/logrotate.d/*) cf man logrotate.

    • [^] # Re: dumpe2fs /dev/hda6

      Posté par  (site web personnel) . Évalué à 2.

      Pour la différence entre la taille de la partition != l'espace disque libre + l'espace disque utilisé : Il s'agit des "reserved blocks" : sur un fs en ext2 (ou ext3) tu auras toujours des blocks reservés. Tu peux voir leur comptage actuel avec dumpe2fs et en changer le nombre avec tune2fs.

      Oui, c'est ce dont je parlais mais je n'avais pas pu y remettre un nom, j'avais essayé, ça m'avait fait gagner un tout petit peu, mais ça n'expliquait pas tout.

      • [^] # Re: dumpe2fs /dev/hda6

        Posté par  . Évalué à 0.

        slt ,

        Pour savoir quels sont tes répertoires qui occupent le plus d'espace, rends toi dans ton répertoire /var et exécute du -sh *

        tu auras la vraie taille des fichiers et répertoires.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.