/ tmp directory: 0 file ma mostra pieno?

3

Relativo a un altro post in cui sono stato finalmente in grado di eliminare i file all'interno di / tmp grazie a un altro poster.

Tuttavia, alla fine il sysadmin ha dovuto ripristinare uno snapshot di qualche giorno fa per ripristinare il servizio mysql.

Ho dedotto che il server mysql non era in esecuzione, e non lo era. Un errore era che non poteva scrivere nella directory tmp per creare i file mysqld.sock / .pid in modo che non esistessero.

Quindi il server è stato riavviato / riavviato e finalmente ripristinato da uno snapshot precedente, quindi tutto ora funziona, ma quell'istantanea era di qualche giorno fa quindi i segnali di tell-tell sono in questo output:

drwxrwxrwt  2 root  root  34471936 Oct  8 20:47 tmp

Quel grosso numero viene ancora "ricordato" in qualche modo e sto cercando di scoprire cosa scrive in quella cartella? In Drupal, il percorso per i file di anteprima è impostato su quella directory, ma ho appena fatto una serie di test (il sito non ha account di accesso / solo per i dati), download, anteprima ecc. E il numero del file non è mai cambiato nella cartella / tmp sta scrivendo su quella cartella?

Questo è un server web che non viene spento / riavviato a meno che non ci sia qualche problema. Anche così, la directory / tmp non si svuota al riavvio. Inoltre, nel file rsC, TMPTIME=0 è ancora al valore predefinito.

Quindi, non sono sicuro su quale altro aspetto o come indagare su cosa sta mantenendo quella dimensione di 3441936 quando la directory effettiva è vuota? Oppure, come cercare i processi che stanno usando quella directory.

Questo è solo per un'installazione Drupal. Ubuntu 12.

    
posta kelly johnson 16.10.2013 - 23:47

2 risposte

6

Prova questo.

$ sudo lsof | egrep '^COMMAND|deleted'

Esempio di output che vedo sul mio sistema ...

COMMAND     PID        USER   FD      TYPE             DEVICE   SIZE/OFF       NODE NAME
mysqld     2842      mysql    5u      REG                9,1        4633    6209543 /tmp/ibLRNV1i (deleted)
mysqld     2842      mysql    6u      REG                9,1         424    6209545 /tmp/ibnnYl1y (deleted)
mysqld     2842      mysql    7u      REG                9,1           0    6209546 /tmp/ib5ViM0O (deleted)
mysqld     2842      mysql    8u      REG                9,1           0    6209547 /tmp/ibh9U55F (deleted)
mysqld     2842      mysql   13u      REG                9,1           0    6209548 /tmp/ibRzqtwm (deleted)
mysqld     2842      mysql  319u      REG                9,1    25894907    6209553 /tmp/MLFxqPDX (deleted)
mysqld     2842      mysql  350u      REG                9,1   267677827    6209550 /tmp/MLFBkHbP (deleted)

Una caratteristica comune di molti filesystem * nix è il fatto che non c'è nulla che impedisca a un processo di continuare a leggere / scrivere / da un file eliminato, e non c'è nulla che impedisca l'eliminazione di un file che un processo ha ancora aperto.

In un modo, alcuni programmi assicurano che i file temporanei non durino a lungo (e forse anche come misura di sicurezza, anche se non sono sicuro di quanto sia "sicuro") è quello di aprirli e immediatamente "scollegare" (eliminare) loro. Se il processo termina in modo imprevisto, lo spazio su disco viene liberato. MySQL fa questo:

  

MySQL ordina che i file temporanei vengano rimossi se mysqld viene terminato. Sulle piattaforme che lo supportano (come Unix), questo viene fatto scollegando il file dopo averlo aperto. Lo svantaggio di questo è che il nome non appare negli elenchi di directory e non si vede un grande file temporaneo che riempie il file system in cui si trova la directory di file temporanea. (In questi casi, lsof + L1 può essere utile per identificare file di grandi dimensioni associati a mysqld.)

     

- link

Punto importante: quando un file che è ancora aperto viene eliminato, lo spazio non viene effettivamente liberato sul disco fino a quando l'ultimo processo che contiene un handle sul file lo chiude. Fino a quando il file non viene chiuso, nessuno, inclusa la radice, può liberare tale spazio se non uccidendo il processo. Viceversa, uccidendo (o fermando con grazia, se possibile) il processo dovrebbe sempre liberare lo spazio.

Quindi ti consiglio di dare un'occhiata a ciò che il tuo sistema potrebbe avere in termini di file aperti e cancellati e questo potrebbe darti qualcosa da fare.

Nel caso del mio sistema, MySQL ha un certo numero di file temporanei aperti, alcuni dei quali abbastanza grandi.

Se vuoi dare un'occhiata a quei file, è facile, anche se la natura di ciò che sarai in grado di discernere varia molto. Prendi il PID e le cifre sotto FD che fanno questo ... esempio, PID 2842 FD 350:

$ sudo strings /proc/2842/fd/350 | less

Se MySQL ha cancellato i file temporanei aperti, l'arresto e il riavvio di MySQL libereranno lo spazio, e quindi dovrai indagare su quali potrebbero essere mantenuti quelli aperti perché persistono più a lungo del necessario e se hai domande che sono generando tabelle temporanee eccessivamente grandi e esaurendo lo spazio / tmp. Se la tua directory / tmp è propria partizione / filesystem allora df -h ti darà una risposta migliore per quanto riguarda lo spazio libero e usato. Probabilmente non ti devi preoccupare troppo delle dimensioni effettive della voce della directory stessa.

E ovviamente potrebbe non essere MySQL. :)

    
risposta data Michael - sqlbot 17.10.2013 - 02:25
0

ext [234] non riduce la dimensione delle directory quando si eliminano i file; contrassegna semplicemente le voci come eliminate in modo che possano essere riutilizzate in seguito. Se vuoi veramente reclamare quei 34 MB, dovrai eliminare e ricreare la directory, oppure avviare la modalità di ripristino ed eseguire e2fsck -D sul volume.

    
risposta data psusi 17.10.2013 - 00:26

Leggi altre domande sui tag