☰

为什么 apt-cache 这么慢？

tag-icon • tag-icon apt 14.04
为什么 apt-cache 这么慢？

从 Saucy (13.10) 升级到 Trusty (14.04) 后，所有 apt 操作都非常慢。即使那些不包含下载任何内容或连接到任何服务器的操作也是如此。例如，显示 apt 策略

# time apt-cache policy 

[...]

real    0m8.951s
user    0m5.069s
sys     0m3.861s

需要将近十秒钟！主要是在发出命令后立即出现奇怪的延迟。即使我再次发出相同的命令，情况也是一样的。

在另一个系统上，它不需要十分之一秒

real    0m0.096s
user    0m0.070s
sys     0m0.023s

另一个系统稍微强大一些，但升级前没有明显的区别。

它和 apt-get 以及任何与 apt 相关的东西都一样。我该如何找出造成这种延迟的根源并修复它？

附加信息：

# cat /etc/nsswitch.conf 

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

顺便问一下，我对 apt-cache 工作原理的理解正确吗？运行时它不会建立任何网络连接apt-cache policy，对吗？

如果我错了，而且这很重要，以下是我的资料来源https://gist.github.com/anonymous/02920270ff68e23fc3ec

答案1

打开终端并首先安装 bleachbit

sudo apt-get install bleachbit

然后以 sudo 身份运行 bleachbit：

sudo bleachbit

然后进行清理，你会看到事情开始进展得更快:)

答案2

这不是一个直接的答案，而是一个帮助找出正在发生的事情的一些追踪提示。

  • 使用strace没有connect，即它没有尝试连接任何服务器（进程没有打开任何套接字）

    strace -c  apt-cache policy > /dev/null

    追踪它，相对时间：

    strace -r -o apt-cache.trace apt-cache policy > /dev/null

    查看哪个步骤花费的时间更长：

    cat apt-cache.trace | sort | tail -20

    请记住，这是相对计时，这意味着当前调用显示相对于前一个调用的开始时间。换句话说，这是前一个调用所花费的原始时间。然后您必须返回才能apt-cache.trace知道是哪个调用。使用该方法的简单方法grep是在匹配前给出 10 行：

    grep -B10 0.008271 apt-cache.trace

  • 但是我认为strace 这是一种先进的工具，我建议尝试ioprofiler为 IO 性能提供 GUI。

    1. 安装

      sudo apt-get install python-matplotlib python-qt4
make profiler
sudo make install_profiler

    2. 跟踪 apt-cache

      ioprofiler-trace apt-cache policy

    3. 打开结果

      ioprofiler ioproftrace.log

答案3

根据我的经验，如果 apt 已知的软件包数量非常多，则 apt 操作的延迟是很自然的。要知道软件包的数量，请运行。apt-cache stats在两台计算机上执行此操作并显示输出。
考虑以下情况。从 live iso（位于 HDD 中）启动后，apt 操作apt-get install需要不到一秒钟的时间。apt 已知的软件包数量约为 7k。在添加一些软件源（例如来自 universe、main 的软件包）后，apt 知道约 50k 个软件包。现在该命令apt-get install需要约 9 秒（构建依赖关系树等）。现在缓存大小约为 60 MB

答案4

根据我的测试，之所以速度如此之慢是因为apt-cache policy some-package迭代文件描述符直到达到限制错误。

~# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04 LTS"
~# ulimit -n 65535; time apt-cache policy snmpd
snmpd:
  Installed: 5.7.2~dfsg-8.1ubuntu3
  Candidate: 5.7.2~dfsg-8.1ubuntu3
  Version table:
 *** 5.7.2~dfsg-8.1ubuntu3 0
        100 /var/lib/dpkg/status

real    0m3.611s
user    0m0.432s
sys     0m0.264s
~# ulimit -n 100; time apt-cache policy snmpd
snmpd:
  Installed: 5.7.2~dfsg-8.1ubuntu3
  Candidate: 5.7.2~dfsg-8.1ubuntu3
  Version table:
 *** 5.7.2~dfsg-8.1ubuntu3 0
        100 /var/lib/dpkg/status

real    0m0.108s
user    0m0.011s
sys     0m0.016s

例如，我在跟踪该过程时看到这样的内容：

[pid 10447] fcntl(65534, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor)
[pid 10447] getrlimit(RLIMIT_NOFILE, {rlim_cur=65535, rlim_max=65535}) = 0

我认为这表明 apt-cache 中存在错误。解决此问题的一种不成熟的方法是限制打开文件的数量，但在某些情况下这可能会导致不必要的失败。

相关内容