Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

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

share|improve this question
    
Bad hard drive? –  saiarcot895 Jun 6 at 17:40
    
too much cache? –  Virusboy Jun 6 at 17:43
    
@saiarcot895 SMART says it's fine. gist.github.com/anonymous/de0d934288ba2479728b –  Damn Terminal Jun 6 at 17:46
1  
apt-cache - query the APT cache.apt-cache performs a variety of operations on APT's package cache. IMO, speed of querying the database is completely based on the processor and the size of your RAM. –  Avinash Raj Jun 11 at 3:09
1  
@DamnTerminal Have you tried sudo apt-get clean or sudo apt-get autoclean & sudo apt-get autoremove? –  Pandya Jun 13 at 6:31

6 Answers 6

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 :)

share|improve this answer

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

share|improve this answer
    
I've seen similar results, although with different hardware the times are different. This makes perfect sense to me. –  Elder Geek Jun 17 at 15:12

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
      
share|improve this answer

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...

share|improve this answer

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.

share|improve this answer
    
With help from a colleage I found that this was the solution. echo 'APT::Architectures { "amd64"; };' > /etc/apt/apt.conf.d/01arch. –  Michael Hale Jul 22 at 16:17

Try this: Do a clean installation of 14.04 instead of just upgrading from a previous non-LTS version.


PS:

I saw your post here also: Lag on apt-get operations after upgrade to Trusty (14.04), and realized you are using the machine as a server.

As side notes for this: First, production servers normally use LTS. Second, they are normally upgraded after the first point release update arrives, not when LTS is freshly released. This allows for many bugs to be fixed first before going live for a server.

Check first comment here: Upgrading LTS to LTS (server) -- why wait for the first point release?

Hope this helps.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.