ディスク上の多数のファイルを効率的に読み取る方法に興味があります。ファイルをデバイスごとに並べ替えてから、inode ごとに並べ替えると、ファイルの自然な読み取りに対して速度が向上するかどうかを知りたいです。
1498 次
3 に答える
2
1970 年代にさかのぼると、シーク時間を最小限に抑えるような方法でディスクの読み取りおよび/または書き込みのキューを整理すれば、ディスクからの読み取り/ディスクへの書き込みが全体的に高速になることをコンピューター センターに提案しました。多くの研究がいくつかの手法で行われ、ディスクの読み取り/書き込みが先着順で行われた場合に JOBS (単一のジョブだけでなく) の全体的なスループットが最適になるという実験と IBM からの情報をコンピュータ センターに提供しました。これは IBM のバッチ システムでした。
于 2012-08-05T07:23:38.770 に答える
1
一般に、ファイル アクセスの最適化手法は、ストレージ サブシステムのアーキテクチャにあまりにも結びつきすぎているため、ソート アルゴリズムのような単純なものにはなりません。
1) ファイルが複数の物理ドライブ (パーティションだけでなく) に分散されていて、異なるドライブから 2 つ以上のファイルを並行して読み取る場合、読み取りデータ速度を効果的に増やすことができます。これはおそらく実装が簡単な唯一の方法です。
2) ファイルを名前または inode 番号でソートしても、一般的には何も変わりません。必要なのは、ディスク上のブロックの物理的な場所でファイルを並べ替えて、最小限のシークで読み取ることができるようにすることです。ただし、かなりの数の障害があります。
ほとんどのファイルシステムは、デバッグの理由がない限り、ユーザー空間アプリケーションにそのような情報を提供しません。
各ファイルのブロック自体は、特にほぼ完全なファイルシステムでは、ディスク全体に分散する可能性があります。前後にシークせずに複数のファイルを順番に読み取る方法はありません。
プロセスがストレージ サブシステムにアクセスする唯一のプロセスであると想定しています。少なくとも他の誰かが同じことをしたら、思いついたすべての最適化は窓の外に出ます.
オペレーティング システムや独自のキャッシュおよび I/O スケジューリング メカニズムよりも賢くなろうとしています。カーネル、つまりシステムと使用パターンを本当に知っている唯一のカーネルを推測しようとすると、事態が悪化する可能性が非常に高くなります。
たとえば、PostreSQL や Oracle が同様の手法を使用できるとしたら、それを使用したと思いませんか? DBが適切なファイルシステムにインストールされている場合、カーネルにそのことを任せ、その決定を再推測しようとしません。DB が raw デバイス上にある場合にのみ、物理ブロックを考慮した特殊な最適化アルゴリズムが機能します。
また、ストレージ デバイスの特定のプロパティも考慮する必要があります。たとえば、最新の SSD は、従来のシーク時間の最適化を時代遅れにします。
于 2011-02-28T17:18:50.960 に答える