У меня есть каталог с ~2 миллионами символических ссылок, которые указывают на реальные файлы на том же диске, который является настоящим локальным жестким диском (это не сетевое монтирование). Все имена файлов уникальны, и файлы, на которые они указывают, разбросаны по разным каталогам, но все они имеют один и тот же родительский путь. Я объединяю файлы в нескольких каталогах с помощью символических ссылок.
/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 строк, а затем останавливается, время от времени добавляя несколько тысяч результатов.
Почему он может заглохнуть? И можно ли сделать вторую команду такой же быстрой, как и первая?
Редактировать: вообще /tmpне отображается mount(так что я предполагаю, что это не tmpfs). Согласно htop, у меня не мало памяти; у меня свободно около 50 ГБ. Загрузка ЦП также низкая. Для find -L path, который зависает, /tmp/fooсоставляет около 90 МБ, когда происходит замедление. Для find path, который не зависает, /tmp/fooсоставляет 111 МБ.
У меня такое же замедление при перенаправлении вывода в ~/foo.
Редактировать: При визуальном наблюдении iotopотображается find -Lзначение ввода-вывода 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/настройка-linux-кэша-для-кэширования-inode
подробнее о настройке дисков:https://unix.stackexchange.com/questions/30286/can-i-configure-my-linux-system-for-more-aggressive-file-system-caching/41831