Для определенного каталога DIR в моей системе ls --color=always занимает около 8 секунд, хотя содержит менее 10 файлов и подкаталогов. Без аргумента о цвете это не займет много времени.
Почему бы ls так долго рассуждая о цвете, и как я могу узнать, что именно занимает так много времени? Вероятно, это какой-то подкаталог в DIR, который смонтирован, но как я могу узнать, какой из них является источником проблем?
Просто отключили цвет на серверах на моей работе. Согласно этому блогу: http://www.techper.net/2011/01/25/ls-command-slow-on-very-large-directories/
Это может быть связано с тем, что функция stat () вызывается на всех различных монтировках в определенном каталоге для получения информации, представленной цветами ...
В этом легко убедиться:
time command ls /dir/with/many/toplevel/entries/ >/dev/null
time $SHELL -c "ls --color=always /dir/with/many/toplevel/entries/ >/dev/null"
Первая команда для созданной мной проблемной структуры каталогов дает:
real 0m0.523s
user 0m0.284s
sys 0m0.052s
И второй:
real 1m47.799s
user 0m0.360s
sys 0m0.928s
Имейте в виду, что если вы повторите нижний «тест», его второй запуск будет иметь данные stat () уже в кеше. Второй запуск цветного вывода дал мне:
real 0m0.409s
user 0m0.256s
sys 0m0.120s
Мне не удалось полностью очистить кеш, чтобы обеспечить воспроизведение результата «более 90 секунд». В vm.drop_caches sysctl, как описано в https://stackoverflow.com/questions/599719/how-to-clean-caches-used-by-the-linux-kernel было недостаточно.
Попробуйте выполнить ls с помощью * s, чтобы перечислить только определенные вещи и посмотреть, какие комбинации медленные.
Некоторые цветовые конфигурации выглядят глупо и читаются в файле содержание. Проверьте свою конфигурацию. Я использую раскрашенные ls, но только так, чтобы lstat предоставлял всю необходимую информацию.