`du`サマリーをキャッシュする、または高速化する方法は？

完全なdu（ディスク使用量）サマリーが2分以上かかる大きなファイルシステムがあります。そのファイルシステム上の任意のディレクトリのディスク使用量の概要を高速化する方法を見つけたいです。

小規模なブランチのdu場合、繰り返しのリクエストがはるかに高速であるため、結果が何らかの形でキャッシュされているように見えることに気付きましたが、大規模なブランチではスピードアップは無視できます。

du前の検索以降に変更されていないブランチの結果を高速化する、またはより積極的にキャッシュする簡単な方法はありますか？

または、ディスク使用量の概要をより迅速に配信できる代替コマンドはありますか？

duコマンドを再実行したときに表示されるのは、ディスクバッファリングの影響です。ブロックを読み取ると、そのブロックが必要になるまで、ディスクバッファーはバッファーキャッシュに保持されます。duの場合、ディレクトリ内の各ファイルのディレクトリとiノードを読み取る必要があります。この場合、duの結果はキャッシュされませんが、はるかに少ないディスクIOで取得できます。

システムにこの情報を強制的にキャッシュさせることは可能ですが、必要なバッファスペースがアクティブにアクセスされたファイルに使用できないため、全体的なパフォーマンスが低下します。

ディレクトリ自体にはファイルのサイズがわからないため、各ファイルのiノードにアクセスする必要があります。ファイルのサイズが変更されるたびにキャッシュ値を最新に保つには、キャッシュ値を更新する必要があります。ファイルは0個以上のディレクトリにリストできるため、各ファイルのiノードがリストされているディレクトリを知る必要があります。これにより、iノード構造が大幅に複雑になり、IOパフォーマンスが低下します。また、duを使用すると、異なるブロックサイズを想定して結果を取得できるため、キャッシュに必要なデータは、ブロックサイズごとにキャッシュ値をインクリメントまたはデクリメントする必要があり、パフォーマンスがさらに低下します。

ファイルのさまざまな階層をさまざまなグループに属するように調整できる場合は、ディスククォータを設定できます。必要な場合を除き、上限を指定しないでください（または、ディスクのサイズにしてください）。グループが使用している（実質的に無限の）割り当て量を即座に知ることができます。

これには、ファイルシステムがグループごとのクォータをサポートしている必要があります。LinuxのExt [234]およびSolaris / * BSD / Linuxのzfsはサポートしています。グループクォータがACLを考慮に入れた場合、ユースケースに適していますが、そうは思わないでしょう。

の一般的な使用法は、duを使用して非常に高速化できますncdu。

ncdu - NCurses Disk Usage

を実行しdu、結果をキャッシュし、素敵なコマンドラインguiで表示しdu -hc -d 1 | sort -hます。duすべてのサブディレクトリには最初にキャッシュされたdu情報があるため、最初のインデックス作成にはの場合と同じくらい時間がかかりますが、貴重なスペースを埋める実際の「犯人」の検索は高速化されます。

必要なサブディレクトリは[r]を押して更新でき、ファイル/フォルダは[d]を押して削除できます。どちらもすべての親ディレクトリの統計を更新します。削除は確認を求めます。

必要な場合ncdu -1xo- / | gzip >export.gzは、cronジョブを事前キャッシュし、後ででアクセスすることでさらに高速化できますzcat export.gz | ncdu -f-が、明らかにより古い情報が得られます。

私はageduを使用することを好みます

Ageduは、これらのファイルが必要とされない可能性が最も高いという前提で、古くて不規則に使用されているファイルを見つけようとするソフトウェアです。（たとえば、一度だけ表示されたダウンロード。）

基本的に、と同じ種類のディスクスキャンduを実行しますが、スキャンするすべての最終アクセス時刻も記録します。次に、各サブディレクトリの結果の概要を示すレポートを効率的に生成できるインデックスを作成し、オンデマンドでそれらのレポートを作成します。

SHWで述べたように、agedu実際にインデックスを作成しました。について読んだ後、インデックスを作成する別の方法を共有すると思いましたlocatedb。locatedbfrom du出力の独自のバージョンを作成できます。

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

awkduの出力を再配置して、最初にファイル名を持つようにしますfrcode。次にlocate、このデータベースを使用して、ディスクの使用状況をすばやく報告します。

locate --database=du.locatedb pingus

これをニーズに合わせて拡張できます。Locatebの良い使い方だと思います。

duc

（https://duc.zevv.nlを参照）が探しているものかもしれません。

Ducは最適化されたデータベースにディスク使用量を保存するため、ユーザーインターフェイスが高速になります。インデックスが完成したら待ち時間はありません。

インデックスの更新は非常に高速です（121kのディレクトリにある950kのファイル、2.8 TBで10秒未満）。GUIとncurses UIもあります。

使用例：

duc index /usr
duc ui /usr

ウェブサイトから：

Ducは、巨大なファイルシステムに合わせて拡張できるように構築されています。ペタバイト規模のストレージ上の何億ものファイルを問題なくインデックス付けして表示します。

10分ごとにupdatedbを実行するようにcronジョブを設定しています。すべてのファイルシステムバッファをきれいに保ちます。安価なRAMを良いものに使用することもできます。slabtopを使用して、「前」と「後」を参照してください。

ディレクトリのサイズのみを知る必要がある場合は、画面への情報の書き込みを避けるだけで、ディレクトリの速度を大幅に上げることができます。総計はduコマンドの最後の行であるため、単純にそれをにパイプできますtail。

du -hc | tail -n 1

2GBのディレクトリ構造では、リスト全体が1秒以上かかりますが、このフォームでは5分未満です。