同じドライブ (実際のローカル ハード ディスク) 上の実際のファイルを指す約 200 万のシンボリック リンクを持つディレクトリがあります (ネットワーク マウントではありません)。ファイル名はすべて一意で、指しているファイルはさまざまなディレクトリに分散していますが、すべて同じ親パスを共有しています。シンボリック リンクを使用して、複数のディレクトリにあるファイルを統合しています。
/some/full/path/consolidated/my_file -> /some/full/path/mydir2/my_file
/some/full/path/consolidated/my_file2 -> /some/full/path/mydir3/my_file2
/some/full/path/consolidated/my_file3 -> /some/full/path/mydir4/my_file3
/some/full/path/consolidated/my_file4 -> /some/full/path/mydir4/my_file4
/some/full/path/consolidated/my_file5 -> /some/full/path/mydir2/my_file5
/some/full/path/consolidated/my_file6 -> /some/full/path/mydir3/my_file6
シンボリックリンクが壊れないことが保証されます。
問題はそれです
time find "/some/full/path/consolidated/" -maxdepth 1 -type l -print > /tmp/foo
すぐに終わります:
1.24 user 0.83 system 0:02.08elapsed
しかし、
time find -L "/some/full/path/consolidated/" -maxdepth 1 -type f -print > /tmp/foo
に続く
watch wc -l /tmp/foo
非常に速く約 660,000 行に到達し、その後停止し、時々数千行の結果が追加されることがわかります。
なぜ停止してしまうのでしょうか? また、2 番目のコマンドを最初のコマンドと同じくらい速くすることは可能ですか?
編集:
/tmpにはまったく表示されませんmount(したがって、tmpfs ではないと想定しています)。htop によると、メモリ不足ではありません。空き容量は約 50 GB です。CPU 使用率も低いです。find -L path停止する の場合、/tmp/foo速度低下が発生すると約 90 MB になります。find path停止しない の場合、/tmp/foo111 MB になります。
出力を ~/foo にリダイレクトする場合も同様に速度が低下します。
編集: 目視するとiotop、find -LI/O が 99.99% と表示されますが、これは約 10 秒後であり、通常の処理findが完了するよりもかなり後です。
答え1
inodeキャッシュを増やしてみてください
echo 50 | sudo tee /proc/sys/vm/vfs_cache_pressure
値100は平均で、値が低いほどinode+dentryキャッシュが大きくなります。
欠点: キャッシュが大きくなります。遅くなる可能性があるキャッシュを減らすこともできます
echo 200 | sudo tee /proc/sys/vm/vfs_cache_pressure
または、キャッシュされたファイルリストを使用して
sudo updatedb
locate /some/full/path/consolidated
また、inode の使用状況にも注意してください。シンボリックリンクは inode を占有します (ハードリンクも同様)
df -i
関連している：https://serverfault.com/questions/338097/tuning-linux-cache-settings-for-inode-caching
ディスクチューニングの詳細:https://unix.stackexchange.com/questions/30286/can-i-configure-my-linux-system-for-more-aggressive-file-system-caching/41831