Come memorizzare nella cache o accelerare in altro modo i riepiloghi `du`?

Abbiamo un file system di grandi dimensioni in cui un duriepilogo completo (utilizzo del disco) richiede più di due minuti. Vorrei trovare un modo per accelerare un riepilogo dell'utilizzo del disco per le directory arbitrarie su quel file system.

Per i rami piccoli ho notato che i durisultati sembrano in qualche modo memorizzati nella cache, poiché le richieste ripetute sono molto più veloci, ma su rami grandi la velocità diventa trascurabile.

Esiste un modo semplice per accelerare duo memorizzare i risultati nella cache in modo più aggressivo per i rami che non sono stati modificati dalla ricerca precedente?

Oppure esiste un comando alternativo in grado di fornire più rapidamente i riepiloghi sull'utilizzo del disco?

Quello che vedi quando esegui di nuovo un comando du è l'effetto del buffering del disco. Una volta letto un blocco, il relativo buffer del disco viene mantenuto nella cache del buffer fino a quando non è necessario quel blocco. Per du è necessario leggere la directory e l'inode per ciascun file nella directory. I due risultati non vengono memorizzati nella cache in questo caso, ma possono essere derivati ​​con molto meno IO del disco.

Mentre sarebbe possibile forzare il sistema a memorizzare queste informazioni nella cache, le prestazioni complessive risentirebbero in quanto lo spazio buffer richiesto non sarebbe disponibile per i file a cui si accede attivamente.

La directory stessa non ha idea di quanto sia grande un file, quindi è necessario accedere all'inode di ogni file. Per mantenere aggiornato il valore memorizzato nella cache ogni volta che un file cambia dimensione, il valore memorizzato nella cache deve essere aggiornato. Poiché un file può essere elencato in 0 o più directory, ciò richiederebbe che l'inode di ogni file conosca le directory in cui è elencato. Ciò complicherebbe notevolmente la struttura dell'inode e ridurrebbe le prestazioni di I / O. Inoltre, poiché du consente di ottenere risultati assumendo dimensioni di blocco diverse, i dati richiesti nella cache dovrebbero aumentare o diminuire il valore memorizzato nella cache per ogni possibile dimensione del blocco, rallentando ulteriormente le prestazioni.

Se è possibile disporre che le diverse gerarchie di file appartengano a gruppi diversi, è possibile impostare le quote del disco . Non dare un limite superiore (o renderlo delle dimensioni del disco) a meno che tu non lo desideri. Sarai comunque in grado di dire all'istante quanta parte della sua quota (effettivamente infinita) sta usando il gruppo.

Ciò richiede che il file system supporti le quote per gruppo. Ext di Linux [234] e Solaris / * BSD / Linux di zfs. Sarebbe bello per il tuo caso d'uso se le quote di gruppo prendessero in considerazione gli ACL, ma non credo che lo facciano.

L'uso comune di dupuò essere velocizzato immensamente usando ncdu.

ncdu - NCurses Disk Usage

esegue il du, memorizza nella cache i risultati e li mostra in una bella interfaccia a riga di comando, in qualche modo paragonabile a du -hc -d 1 | sort -h. L'indicizzazione iniziale richiede altrettanto tempo du, ma la ricerca dell'effettivo "colpevole" che riempie lo spazio prezioso viene accelerata, poiché tutte le sottodirectory hanno le informazioni inizialmente memorizzate nella cache.

Se necessario, le sottodirectory possono essere aggiornate premendo [r] e i file / le cartelle possono essere eliminati premendo [d], entrambi i quali aggiornano le statistiche per tutte le directory principali. L'eliminazione chiede conferma.

Se necessario, è possibile ottenere un'ulteriore accelerazione eseguendo il precaching ncdu -1xo- / | gzip >export.gzin un cronjob e accedendo successivamente ad esso zcat export.gz | ncdu -f-, ma ovviamente fornisce informazioni più obsolete.

Preferisco usare il ageu

Agedu è un software che tenta di trovare file vecchi e usati in modo irregolare presumendo che questi file probabilmente non saranno desiderati. (ad es. download che sono stati visualizzati solo una volta.)

Fa praticamente lo stesso tipo di scansione del disco du, ma registra anche i tempi dell'ultimo accesso di tutto ciò che scansiona. Quindi crea un indice che gli consente di generare report in modo efficiente fornendo un riepilogo dei risultati per ciascuna sottodirectory e quindi produce tali report su richiesta.

Come menzionato da SHW, ageduinfatti ha creato un indice. Ho pensato di condividere un altro modo per creare un indice, dopo aver letto locatedb. È possibile creare la propria versione di un locatedbda duuscita:

du | awk '{print $2,$1}' | /usr/lib/locate/frcode > du.locatedb

awkriorganizza l'output du per avere prima i nomi dei file, in modo che frcodefunzioni correttamente. Quindi utilizzare locatecon questo database per segnalare rapidamente l'utilizzo del disco:

locate --database=du.locatedb pingus

Puoi espanderlo per soddisfare le tue esigenze. Penso che sia un buon uso di locatedb.

duc

(vedi https://duc.zevv.nl ) potrebbe essere quello che stai cercando.

Duc memorizza l'utilizzo del disco in un database ottimizzato, ottenendo un'interfaccia utente veloce. Nessun tempo di attesa una volta completato l'indice.

L'aggiornamento dell'indice è molto rapido per me (meno di 10 secondi per circa 950.000 file in directory 121.000, 2,8 TB). Ha anche una GUI e un'interfaccia utente ncurses.

Utilizzo ad es .:

duc index /usr
duc ui /usr

Dal sito Web:

Duc è progettato per adattarsi a enormi filesystem: indicizzerà e visualizzerà centinaia di milioni di file su petabyte di spazio di archiviazione senza problemi.

Ho un cronjob impostato per essere aggiornatob ogni 10 minuti. Mantiene tutti i buffer dei filesystem belli e freschi. Potrebbe anche usare quella RAM economica per qualcosa di buono. Usa slabtop vedi 'prima' e 'dopo'.

Se hai solo bisogno di conoscere la dimensione della directory, puoi accelerarla molto semplicemente evitando di scrivere le informazioni sullo schermo. Poiché il totale generale è l'ultima riga del ducomando, puoi semplicemente reindirizzarlo tail.

du -hc | tail -n 1

Una struttura di directory da 2 GB occupa un secondo per l'elenco completo ma meno di un quinto di quello con questo modulo.