Why is apt-cache so slow?

Question

After upgrade to Trusty (14.04) from Saucy (13.10), all apt operations are very slow. Even those that do not include downloading anything, or connecting to any servers. For example, displaying the apt policy

# time apt-cache policy 

[...]

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

takes almost ten seconds! Mostly a weird lag right after issuing the command. And it's the same even if I issue the same command again.

On another system it doesn't take a tenth of a second

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

The other system is a little beefier but there was no noticeable difference before the upgrade.

It's the same with apt-get, anything apt-related. How do I find out the source of this lag and fix it?

Additional info:

# 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

BTW is my understanding of how apt-cache works correct? It doesn't make any network connections when I run apt-cache policy, right?

In case I'm wrong and it matters, here are my sources https://gist.github.com/anonymous/02920270ff68e23fc3ec

Answer 1

Open terminal and first install bleachbit

sudo apt-get install bleachbit

Then run bleachbit as sudo:

sudo bleachbit

Then perform a cleanup and you will see that things start going much faster :)

Answer 2

This not attended to be a direct answer, but some tracing hints to help finding out what's going on.

• Using strace there was no connect, ie. it didn't try connect any server (process didn't open any socket)

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

  Trace it, relative timing:

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

  See which step took longer:

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

  Just remember this is relative timing, meaning current call shows its starting time with respect to previous one. In other words, that's the raw time took by previous call. Then you have get back to apt-cache.trace to know which call was that. A simple way using grep that gives 10 lines before match:

  grep -B10 0.008271 apt-cache.trace
  

• However I think strace is an advanced tool, I suggest trying ioprofiler that provide a GUI for IO performance.

  1. Install it

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

  2. Trace apt-cache

     ioprofiler-trace apt-cache policy
     

  3. Open results

     ioprofiler ioproftrace.log
     

Answer 3

In my experience the delay in apt operation is quite natural, if the number of packages known to apt is very high. To know the number of packages runapt-cache stats. Do it on both computer and show the output.
Consider the following situation. After booting from live iso (located in HDD), apt operation such apt-get install takes less than a second. The number of packages known to apt is ~7k. After adding some software sources such as packages from universe,main the apt know ~50k packages. Now the command apt-get install takes ~9 seconds (building dependency tree etc). Now the cache size is ~60 MB

Answer 4

I noticed that uninstalling the Software Centre and app-install-data speeds up the apt-cache quite a lot now that I use synaptic package manager...

Answer 5

According to my testing the reason this is so slow is because apt-cache policy some-package iterates over file descriptors until it hits a limit error.

~# 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

For example I see this sort of stuff when stracing the process:

[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

I think this points to a bug in apt-cache. One hacky way to work around it would be to limit the number of open files but that could cause things to fail unnecessarily in some cases.