Problème d'espace disque - allocation

Support Debian
#1

Bonjour à tous,

j’administre un serveur, sur lequel tourne une application web, reposant sur PHP / Mysql.

J’ai depuis peu un problème avec l’espace disque, pour lequel je ne trouve pas de solution ni d’explication.

Je dispose en effet d’un disque de 100Go, qui est actuellement occupé à 100% (oui, c’est embêtant).
Quand je lance la commande df -h /, la partition en question est bien inscrite comme occupée à 100%.

Je me dis que je vais faire le ménage, probablement car la taille d’un log a du exploser, ou autre chose du genre, je lance donc la commande du -h --max-depth=1 ./

Et là, le total trouvé est de 68 Go… J’ai donc une trentaine de Go perdue chez Amazon (c’est un serveur virtuel géré chez eux). Cela m’est déjà arrivé il y a deux semaines, donc je sais qu’un reboot règle le problème.

Maintenant est-ce un problème d’allocation de mémoire, de registre, une mémoire virtuelle qui réserve de l’espace disque, ou autre chose du genre que je ne maîtrise pas qui peux poser problème ? Comme je ne suis pas expert système, je me permet de vous solliciter pour comprendre et régler cet épineux problème.

D’avance merci à ceux qui ont des idées sur le sujet,

Cordialement

Benjamin

#2

[quote=“benj75013”]
Je dispose en effet d’un disque de 100Go, qui est actuellement occupé à 100% (oui, c’est embêtant).[/quote]
Au contraire, c’est le fait que le disque ne soit pas occupé à 100% et donc qu’il y ait de l’espace libre inutilisable qui serait embêtant.

C’est complètement autre chose. df affiche l’espace libre et occupé sur les systèmes de fichiers montés, pas sur les disques. Qu’affiche [mono]df -h[/mono] exactement ?

Depuis quel répertoire ? ./ désigne le répertoire courant, pas la racine /.
Y a-t-il un seul système de fichiers racine ou d’autres systèmes de fichiers montés (en dehors des systèmes de fichiers spéciaux tmpfs, /dev, /sysfs…) ?

C’est-à-dire ? Quel est l’espace libre sur / après un redémarrage ?

#3

A première vue je dirais que ton disque fait 68Go et non 100 comme tu le pense … maintenant je peux me tromper hein :033

#4

Merci pour ta réponse.

J’ai deux volumes qui sont ici intéressant. Un qui est monté sur la racine (100Go), et un second monté sur /restoredetar, qui fait 30Go, sur lequel j’ai quelques archives :

La commande df -h me donne actuellement (après un petit nettoyage) :

/dev/xvda1 99G 92G 2.0G 98% /
/dev/xvdp 30G 24G 4.4G 85% /restoredetar

Donc 2 Go de libre seulement. Je suis sûr qu’il doit rester bien plus de dispo sur cette partition.

Effectivement, je lance le “du” à partir de la racine, donc bien du -h --max-depth=1 /, qui me donne un total de 67 Go.

Après le redémarrage, le df -h me donne bien une partition racine avec plus de 30 Go dans la colonne Avail., et donc Use. à 60 et qq %.

#5

Je suis sûr que le disque fait 100Go.

Je lance un fdisk -L pour vous donner plus d’infos

#6

Alors, précisemment, le df -h me donne un total de 63Go, sachant qu’il compte la partition montée sur /restoreredetar, qui est occupée de 24Go de données.

Sur la volume système(/dev/xvda1), je n’ai donc d’après moi, réellement, que 42Go de données (63Go moins les 24 Go comptabilisés, mais qui occupent de la place sur le second volume de 30Go).

Non ?

fdisk -l

Disk /dev/xvda1: 107.4 GB, 107374182400 bytes
255 heads, 63 sectors/track, 13054 cylinders, total 209715200 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/xvda1 doesn’t contain a valid partition table

Disk /dev/xvdp: 32.2 GB, 32212254720 bytes
255 heads, 63 sectors/track, 3916 cylinders, total 62914560 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/xvdp doesn’t contain a valid partition table

#7

df affiche l’espace de chaque système de fichiers pris isolément. Il n’inclut pas les systèmes de fichiers montés par dessus dans les totaux. Il y a 63 Gio occupés sur le volume racine. Les 24 Gio occupés sur l’autre volume n’en font pas partie et sont comptés à part.

Je connais deux raisons pour que la taille occupée rapportée par df ne corresponde pas à la taille occupée visible (mais il y en a peut-être d’autres que je ne connais pas) :

  • des fichiers sont “cachés” sous un point de montage ;
  • des fichiers ont été supprimés et ne sont plus visibles mais sont restés ouverts par un programme, donc l’espace qu’ils occupent n’a pas été libéré tant que le programme ne les ferme pas.

Si des fichiers étaient seulement cachés sous un point de montage, l’espace occupé invisible n’augmenterait pas au cours du temps. S’ils grossissent, c’est probablement qu’ils sont ouverts par un programme qui écrit dedans. Des outils comme lsof ou fuser permettent de rechercher dans les fichiers ouverts.

#8

Ce genre de ligne pourrait t’aider à trouver les fichiers supprimés les plus gros (liste des fichiers ouvert, extraction des fichiers supprimés, selection des colonnes COMMAND, PID et SIZE, tri par la taille, selection des 10 derniers résultats):

sudo lsof | awk '/del/ {print $1, $2, $8}' | sort -k3n | tail
#9

Merci beaucoup, je regarde ça et je vous dis si j’ai trouvé quelque chose, ça pourra servir à d’autres.

Merci pour vos réponses en tout cas.

#10

init 1 7695
mysqld 773 7731
mysqld 773 7756
mysqld 773 8098
mysqld 773 8723
mysqld 773 11447
mysqld 773 131396
mysqld 773 131481
mysqld 773 657601
mysqld 773 657682

Hum, ça ressemble à un problème avec mysql… Après pourquoi il ne libère pas ces fichiers, et donc pourquoi ils restent ouverts après suppression… mystère.

Du coup j’ai redémarré le service mysql et là :

/dev/xvda1 99G 40G 55G 43% /

Merci énormément, à moi de comprendre ce qu’il fabrique avec ces fichiers si volumineux. On a joué avec la config d’innoDB récemment pour gagner en performance, c’est peut être lié…

#11

Le compte n’y est pas, ces tailles sont beaucoup trop petites.
Haleth, n’y aurait-il pas une erreur dans ta commande ? Il me semble que la taille est dans la position 7 et non 8 (qui contient le numéro d’inode du fichier), ça donnerait plutôt :

(j’ai supprimé le PID qui n’apporte pas grand-chose et ajouté le nom du fichier, ça donnera peut-être une indication)

#12

Le champ 8 correspond à "SIZE/OFF"
Nous n’avons peut-être pas la même version de lsof ? 4.86+dfsg-1 quant à moi

#13

En effet j’ai la version 4.81 de Squeeze, qui n’a pas la colonne TID. Néanmoins cette colonne est vide dans certaines lignes, je crains que cela ne fausse le résultat d’awk.