☰

为什么“ls --color=always”对于小目录来说会很慢？

tag-icon • tag-icon filesystems ls
为什么“ls --color=always”对于小目录来说会很慢？

对于我系统上的某个目录 DIR，ls --color=always虽然它包含的文件和子目录不到 10 个，但大约需要 8 秒。如果没有颜色参数，则不需要任何时间。

为什么ls使用颜色参数会花这么长时间？我如何才能找出到底是什么原因花了这么长时间？可能是 DIR 中的某个子目录被挂载了，但我如何才能找出哪个子目录是问题根源？

答案1

他们刚刚禁用了我工作服务器上的颜色。根据此博客： https://web.archive.org/web/20160410082228/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 秒”的结果。sysctlvm.drop_caches如下所述https://stackoverflow.com/questions/599719/how-to-clean-caches-used-by-the-linux-kernel还不够。

答案2

尝试使用 *s 执行 ls 仅列出某些内容，然后查看哪些组合很慢。

答案3

有些颜色配置很愚蠢，读取文件内容。检查您的配置。我使用彩色 ls，但只有这样 lstat 才能提供所有必需的信息。

答案4

根据此错误报告，一个解决方案/解决方法（我可以确认它对我有用）是将以下内容添加到您的~/.profile文件中：

eval `dircolors -b | sed s/or=[^:]*://`

相关内容