私たちは大容量ファイルシステムを持っており、全体du（ディスク使用量）の要約を確認するのに2分以上かかります。このファイルシステム内のランダムディレクトリのディスク使用量の要約を高速化する方法を探したいと思います。
小さなブランチではdu繰り返しの要求がはるかに高速であるため、結果が何とかキャッシュされるように見えましたが、大きなブランチでは速度がわずかでした。
duスピードアップしたり、最後の検索以降に変更されていない四半期の結果をより積極的にキャッシュする簡単な方法はありますか？
それとも、ディスク使用量の要約をより迅速に提供する代替コマンドはありますか？
答え1
duを使用すると、大幅に加速できる一般的な用途ですncdu。
ncdu - NCurses Disk Usage
を実行しduて結果をキャッシュしたら、素晴らしいコマンドラインGUIに表示しますdu -hc -d 1 | sort -h。初期インデックス作成には時間がかかりますが、すべてのサブduディレクトリが最初にキャッシュされているため、貴重なスペースを埋める実際の「犯人」を見つける方が高速です。利用可能。
必要に応じて、[サブディレクトリの更新]をクリックして[ファイルR/フォルダの削除]をクリックすると、両方のすべての親Dディレクトリの統計が更新されます。削除するには確認が必要です。
ncdu -1xo- / | gzip >export.gz必要に応じてcronjobで事前にキャッシュし、後でアクセスして速度をさらに向上させることができますが、zcat export.gz | ncdu -f-これは確かにより古い情報を提供します。
答え2
duコマンドを再実行すると、表示される内容はディスクバッファリングの効果です。ブロックを読み取ると、ブロックが必要になるまで、対応するディスクバッファがバッファキャッシュに保持されます。 duの場合は、ディレクトリとディレクトリ内の各ファイルのinodeを読み取る必要があります。この場合、duの結果はキャッシュされませんが、はるかに少ないディスクIOにエクスポートできます。
システムはこの情報を強制的にキャッシュすることができますが、積極的にアクセスするファイルに必要なバッファスペースを使用できないため、全体的なパフォーマンスに影響します。
ディレクトリ自体はファイルのサイズを知らないため、各ファイルのinodeにアクセスする必要があります。ファイルサイズが変更されるたびにキャッシュされた値を最新の状態に保つには、キャッシュされた値を更新する必要があります。ファイルはゼロ個以上のディレクトリにリストされる可能性があるため、各ファイルのinodeはファイルがリストされているディレクトリを知る必要があります。これにより、inode構造が大幅に複雑になり、IOパフォーマンスが低下します。さらに、duを使用すると、異なるブロックサイズを想定して結果が得られるため、キャッシュに必要なデータは、可能なブロックサイズごとにキャッシュ値を増減する必要があるため、パフォーマンスがさらに低下します。
答え3
duc
（望むよりhttps://duc.zevv.nl）があなたが探しているものかもしれません。
Ducはディスク使用量を最適化されたデータベースに保存し、高速ユーザーインターフェイスを可能にします。索引付けが完了した後、待つ必要はありません。
インデックスの更新は非常に高速です（121kディレクトリに〜950kファイル、2.8TB、10秒未満）。 GUIとncurses UIもあります。
使用例：
duc index /usr
duc ui /usr
ウェブサイトから：
Ducは大規模なファイルシステムに拡張するように設計されています。つまり、ペタバイト規模のストレージにある数億のファイルを問題なくインデックス化して表示します。
答え4
異なるファイル階層が異なるグループに属するように並べ替えることができる場合は、次のように設定できます。ディスククォータ。必要でない限り、上限値を指定したり、ディスクサイズに設定しないでください。グループが使用しているクォータ（実質的に無制限）がどのくらいになるかをすぐに知ることができます。
これを行うには、ファイルシステムが各クォータセットをサポートする必要があります。これは、LinuxのExt [234]とSolaris / * BSD / Linuxのzfsに対応します。グループクォータがACLを考慮している場合は、ユースケースに適しています。しかし、私の考えではそうではありません。