web-dev-qa-db-ja.com

「du」の要約をキャッシュするか、そうでなければ高速化する方法は?

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

小さなブランチの場合、繰り返しリクエストがはるかに高速であるため、duの結果が何らかの形でキャッシュされているように見えますが、大きなブランチでは、速度の向上は無視できるほどになります。

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

または、ディスク使用量の要約をより速く提供できる代替コマンドはありますか?

34
Ian Mackinnon

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

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

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

21
BillThor

aged を使用したい

Ageduは、古くて不規則に使用されているファイルが不要である可能性が高いと想定して、そのファイルを見つけようとするソフトウェアです。(eg Downloads一度しか表示されていません。)

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

9
SHW

duを使用すると、ncduの一般的な使用法を大幅に高速化できます。

ncdu - NCurses Disk Usage

duを実行し、結果をキャッシュして、du -hc -d 1 | sort -hにいくらか似たNiceコマンドラインGUIに表示します。最初のインデックス作成にはduと同じくらい時間がかかりますが、すべてのサブディレクトリに最初にキャッシュされたdu情報が利用できるため、貴重なスペースを埋める実際の「犠牲者」を探すのが高速になります。

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

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

8
DennisH

ファイルの異なる階層を異なるグループに属するように調整できる場合は、 ディスククォータ を設定できます。必要な場合を除いて、上限を指定しないでください(またはディスクのサイズにしてください)。それでも、グループが使用している(事実上無限の)クォータの量を即座に確認することができます。

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

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

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

awkは、du出力を再配置して、ファイル名が最初に来るようにして、frcodeが正しく機能するようにします。次に、このデータベースでlocateを使用して、ディスクの使用状況をすばやく報告します。

locate --database=du.locatedb pingus

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

5
Yuval
duc

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

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

インデックスの更新は私にとって非常に高速です(121kディレクトリの約950kファイル、2.8 TBの場合は10秒未満)。 GUIとncurses UIも備えています。

使用例:

duc index /usr
duc ui /usr

ウェブサイトから:

Ducは巨大なファイルシステムにスケーリングするように構築されています。ペタバイトのストレージで何億ものファイルを問題なくインデックス付けして表示します。

3
Peter

私は10分ごとにupdatedbを実行するようにcronjobを設定しています。すべてのファイルシステムバッファーを最新の状態に保ちます。その安いRAM=何か良いものを使うかもしれません。スラブトップを使って 'before'と 'after'を見てください。

2
Marcin

ディレクトリのサイズを知るだけでよい場合は、画面への情報の書き込みを回避するだけで、ディレクトリを大幅に高速化できます。総計はduコマンドの最後の行なので、単純にtailにパイプできます。

du -hc | tail -n 1

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

2
Frank