du command richiede MODO troppo tempo per essere eseguito


9

Sto correndo du -shin una varietà di directory per trovare maiali del disco. Ho due server identici (Dell PE2850), entrambi con RHEL5 e ci vorrà molto più tempo per funzionare dusu un server rispetto all'altro.

Ad esempio, fare du -sh /opt/foobarci vorranno 5 minuti sul server A (che contiene circa 25 GB) e sul server B, lo stesso comando con la stessa quantità di dati mi riporterà pressoché istantaneo. Non vedo nulla di palesemente evidente quando si corre in alto, ecc.

Qualsiasi consiglio è molto apprezzato.


3
La velocità di du -snon dipende dalla dimensione dei dati ma piuttosto dal numero di file. Entrambi gli alberi delle directory hanno un numero simile di file?
Ladadadada,

2
Inoltre, dufunzionerà molto più velocemente se tutti i metadati della directory (come le dimensioni dei file) sono attualmente memorizzati nella cache. Se questo è il caso per qualsiasi motivo su un server e non sull'altro, comporterà grandi differenze.
Sven

@Ladadada Direi di sì c'è circa la stessa quantità di file. Anche quando si aggiunge l'asterisco per ottenere un elenco delle dimensioni dei file singolarmente, lo scorrimento richiede molto tempo. Ma non sono del tutto sicuro di come verificare se i metadati sono memorizzati nella cache o meno.
Jon Weinraub,

Risposte:


6

Se hai un numero enorme di file in quella directory e il contenuto della directory cambia costantemente, la voce della directory stessa viene frammentata nel tempo. Quindi, quando il sistema operativo legge i contenuti della directory, ci saranno molte e molte ricerche di dischi non necessarie. Ciò accade in particolare con i filesystem ext * (ext4 potrebbe essere migliore però) e con i vecchi filesystem ReiserFS v3.x (se superati dell'85% circa).

La soluzione è abbastanza semplice:

cp -pr origdir newdir
mv origdir origdir.bak
mv newdir origdir

Naturalmente se tutto è memorizzato nella cache nella RAM, questo non ha molta importanza; di solito Linux memorizza nella cache i file e le directory frequentemente utilizzati in modo piuttosto aggressivo. Se vuoi veramente mantenere il contenuto di quelle directory nella RAM, puoi mettere qualcosa di simile ls -lah /your/dir 2>&1 >/dev/nullal tuo cron.

EDIT: Oh, una cosa mi è venuta in mente. Se il tuo server ha un controller RAID con batteria di backup con un po 'di cache, controlla che la batteria sia OK. Ho visto situazioni in cui la batteria è scarica e il controller disabilita completamente la cache, rovinando le prestazioni molto male. Ad esempio, i server HP potrebbero indicare nei registri di iLO qualcosa sulla batteria del controller; nel cruscotto di integrità del server sembra tutto a posto e verde, ma solo la voce di registro ti dirà questo.


1
Probabilmente ci vorrà del tempo per farlo, è su un server di produzione, quindi dovrò farlo durante la notte e l'intera directory contiene diverse centinaia di gigabyte di dati, quindi non voglio impantanarli ... Riferirò prima cosa domani mattina. Grazie per l'idea
Jon Weinraub,

Sto ancora eseguendo questo comando e non sto dicendo quanto tempo ci vorrà. L'ho anche rinnegato e cp è ancora in esecuzione, sono passati circa 1 ora e 15 minuti da quando è stato avviato. Anche l'esecuzione di un du su quella cartella in un'altra shell ha richiesto molto tempo, ma pensi che dovrei fare solo umountil drive fsck?
Jon Weinraub,

Lascialo funzionare a meno che non disturbi in qualche modo la tua produzione. Con RHEL5 e il suo scheduler I / O CFQ predefinito puoi mettere il comando cp nella classe inattiva in modo da non opprimere gli altri processi: ionice -c3 -p $(pidof cp)o giù di lì.
Janne Pikkarainen,

Si prega di leggere anche la mia ultima modifica.
Janne Pikkarainen,

1
So che è passato un po 'di tempo, ma alla fine sono riuscito a eseguire il comando cp di cui hai parlato. Sono necessarie due ore per copiare 25 GB. Dopo aver fatto la sua mossa, correre un altro du -sh è stato altrettanto lento. In effetti, anche la cancellazione della directory di backup è troppo lenta!
Jon Weinraub,

0

Consiglio di provare il semplice comando du senza alcun interruttore. Alla fine vedrai quale directory rallenta il processo. Potrebbe essere un disco difettoso o qualche altro motivo, ...

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.