Une cause probable est la conservation par le système d'exploitation d'un fichier "supprimé" ... mais encore ouvert en écriture :
- Si un processus a ouvert un écriture un fichier (ex : une exploration en boucle infinie),
- Et que vous détruisez ledit fichier (ex : le log de cette exploration),
- Alors l'espace n'est pas libéré tant que les processus Unix associés au batch ne sont pas tués.
Exemple :
L'espace disque est quasi plein (93% - 9Go consommés sur 9.8)
df -g .
Système de fichiers Blocs GB Libre %Util Iutil %Iutil Monté sur
/dev/lv_hradv2a 9,81 0,78 93% 52744 19% /appli/hradv2
Suppression d'un log volumineux
rm ${LOG}/JD800NBW.DIGIX
L'espace n'est pas libéré
df -g .
Système de fichiers Blocs GB Libre %Util Iutil %Iutil Monté sur
/dev/lv_hradv2a 9,81 0,78 93% 52744 19% /appli/hradv2
L'espace consommé par les fichiers présents (3.2 Go) ne correspond pas a l'espace occupé dans le système de fichier (9 Go)
du -ks /appli/hradv2
3252884 /appli/hradv2
L'exploration à la source du log est en fait active.
Elle consomme énormément de puissance (C=120) et tourne depuis 4h25 (15h21 - 10h56).
Elle est probablement en boucle infinie.
ps -fu ${LOGNAME}
UID PID PPID C STIME TTY TIME CMD
hradv2 1228816 1703940 0 15:21:18 pts/31 0:00 -ksh
hradv2 1265740 2015454 0 10:56:23 - 0:00 sh /appli/hradv2/bin/OPER PPHRADV2JD800JD800NBX03PA45977233811DIGIX
hradv2 1515600 1765484 120 10:56:26 - 268:31 /appli/hradv2/bin/RTSDGN /appli/hradv2/prod/gnt/LASS1AEX.so
hradv2 1552476 1515600 0 15:34:42 - 0:00 oraclehradv2 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
hradv2 1765484 1265740 0 10:59:02 - 0:00 sh /appli/hradv2/txt/tmp/JD800NBX.3096756 N
Suppression du processus (kill du Cobol AEX)
kill -9 1515600
L'espace est maintenant libéré (6.76 Go libres)
df -g .
Système de fichiers Blocs GB Libre %Util Iutil %Iutil Monté sur
/dev/lv_hradv2a 9,81 6,76 32% 48252 3% /appli/hradv2
Aucun commentaire:
Enregistrer un commentaire