Por que o apt-cache é tão lento?

Question

Após a atualização para o Trusty (14.04) do Saucy (13.10), todas as operações do apt são muito lentas. Mesmo aqueles que não incluem o download de qualquer coisa ou a conexão com qualquer servidor. Por exemplo, exibindo a política do apt

# time apt-cache policy 

[...]

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

leva quase dez segundos! Principalmente um atraso estranho logo após a emissão do comando. E é o mesmo, mesmo se eu emitir o mesmo comando novamente.

Em outro sistema, não leva um décimo de segundo

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

O outro sistema é um pouco mais robusto, mas não houve diferença perceptível antes da atualização.

É o mesmo com o apt-get, qualquer coisa relacionada ao apt. Como descubro a origem desse atraso e corrijo-o?

Informação adicional:

# 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 é o meu entendimento de como o apt-cache funciona correto? Não faz conexões de rede quando executo apt-cache policy , certo?

Caso eu esteja errado e seja importante, aqui estão minhas fontes link

    

Answer 1

Abra o terminal e primeiro instale o bleachbit

sudo apt-get install bleachbit

Em seguida, execute bleachbit como sudo:

sudo bleachbit

Em seguida, execute uma limpeza e você verá que as coisas começam a ficar muito mais rápidas:)

    

Answer 2

Esta não foi uma resposta direta, mas algumas dicas de rastreamento ajudam a descobrir o que está acontecendo.

• Usando strace não houve connect , ou seja. ele não tentou conectar nenhum servidor (o processo não abriu nenhum soquete)

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

  Rastreie-o, tempo relativo:

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

  Veja qual etapa levou mais tempo:

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

  Lembre-se apenas que é um tempo relativo, o que significa que a chamada atual mostra a hora de início em relação à anterior. Em outras palavras, esse é o tempo bruto recebido pela chamada anterior. Então você volta para apt-cache.trace para saber qual foi a chamada. Uma maneira simples de usar grep que fornece 10 linhas antes da correspondência:

  grep -B10 0.008271 apt-cache.trace
  

• No entanto, acho que strace é uma ferramenta avançada, sugiro tentar ioprofiler que forneça uma GUI para Desempenho de IO.

  1. Instale-o

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

  2. Rastreie o apt-cache

     ioprofiler-trace apt-cache policy
     

  3. Resultados abertos

     ioprofiler ioproftrace.log
     

Answer 3

Na minha experiência, o atraso na operação apt é bastante natural, se o número de pacotes conhecidos no apt for muito alto. Para saber o número de pacotes, execute apt-cache stats . Faça isso no computador e mostre a saída.
Considere a seguinte situação. Depois de inicializar a partir do live iso (localizado no HDD), a operação apt como apt-get install leva menos de um segundo. O número de pacotes conhecidos pelo apt é ~ 7k. Depois de adicionar algumas fontes de software como pacotes do universo, use os pacotes apt ~ 50k. Agora o comando apt-get install leva ~ 9 segundos (construindo árvore de dependência, etc). Agora o tamanho do cache é de ~ 60 MB

    

Answer 4

Notei que desinstalar o Centro de Software e os dados de instalação de aplicativos acelera muito o apt-cache agora que eu uso o gerenciador de pacotes synaptic ...

    

Answer 5

De acordo com o meu teste, o motivo para isso ser tão lento é porque apt-cache policy some-package repete os descritores de arquivo até atingir um erro de limite.

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

Por exemplo, vejo esse tipo de coisa ao aplicar o processo:

[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

Acho que isso aponta para um bug no apt-cache. Uma maneira hacky de contornar isso seria limitar o número de arquivos abertos, mas isso poderia fazer com que as coisas falhassem desnecessariamente em alguns casos.