突然ls -al
需要很长时间才能感到烦人,正常情况下ls
则和往常一样快。
可能存在什么问题?
答案1
运行时ls
它只显示文件列表,没有其他内容。ls -al
另一方面,它显示了更多的信息,为了做到这一点,它必须统计(1)那些文件。
如果文件出现问题,该操作可能会花费很长时间。
我的问题是某些文件的组不再存在
-rw------- 1 nifle 10001 21499 Jan 25 14:31 .bash_history
-rw-r--r-- 1 nifle 10001 304 Dec 6 2004 .bash_logout
-rw-r--r-- 1 nifle 10001 222 Dec 16 14:05 .bash_profile
-rw-r--r-- 1 nifle 10001 124 Dec 6 2004 .bashrc
简单chown nifle:nifle .bash*
解决了这个问题。
答案2
有时它可能是别名问题、shell 的额外处理或对存储设备的访问速度慢。
在我的,我将其作为别名:
$ type ls
ls is aliased to `ls $LS_OPTIONS'
如果是这样的话,运行 as\ls -al
就可以直接调用它。
对于 shell 处理,你可以通过激活 shell 跟踪来检查,例如
$ set -x
$ ls
+ ls -G -h
README.txt index.php
++ update_terminal_cwd
++ local url_path=
++ local i ch hexch LC_CTYPE=C LC_ALL=
++ (( i = 0 ))
++ (( i < 26 ))
++ ch=/
++ [[ / =~ [/._~A-Za-z0-9-] ]]
++ url_path+=/
++ (( ++i ))
++ (( i < 26 ))
++ ch=U
++ [[ U =~ [/._~A-Za-z0-9-] ]]
++ url_path+=U
++ (( ++i ))
++ (( i < 26 ))
++ ch=s
... hundred of other lines
$ set +x
$ echo $PROMPT_COMMAND
update_terminal_cwd
最后检查你的ls
时间:
$ time ls -la
...
real 0m0.025s
user 0m0.001s
sys 0m0.004s
如果您的sys
时间太长,请检查命令load avg
中top
是否有任何东西正在减慢您的机器速度,或者请对您的硬盘进行基准测试,也许您正在进行大量的 I/O 请求(通过:iotop
或检查vmstat
)。
如果这种情况经常发生,请始终使用不同的 shell 或 tmpfs 分区(/tmp
)进行检查,这应该会更快。