La lecture de la liste des paquets prend une éternité


25

J'ai essayé de mettre à jour mes trucs sur ma machine, et il semble qu'il ne puisse pas lire ma liste de paquets. Il semble que chaque fois que je fais sudo apt-get install *something* && sudo apt-get updateça, il se bloque à la lecture de la liste des paquets, cela n'a pas été un problème auparavant. Voici mes spécifications et ainsi de suite:

  • Mémoire: 15,8 Go
  • Processeur: AMD Phenom (tm) II x4 965 Processor x 4
  • Graphisme: Gallium 0.4 sur AMD BARTS
  • Type de système d'exploitation: 32 bits
  • Netspeed: entrez la description de l'image ici

2
Juste pour clarifier ... vous parlez d'exécuter sudo apt-get update, n'est-ce pas?
Jack

2
Dans Software Sources, voyez si la sélection d'un autre serveur, au lieu de votre actuel, aide.

Désolé de ne pas avoir écrit plus sur ce problème. Mais voici l'affaire! chaque fois que j'exécute une mise à jour sudo apt-get, une mise à niveau sudo apt-get ou «sodu apt-get install something », il y parviendra éventuellement, mais cela prend 30 minutes pour lire la liste. J'ai essayé de changer de serveur, et cela n'a pas aidé.
Dre

Quelles sont les spécifications de votre ordinateur et de votre connexion Internet? Modifiez votre question avec de nouvelles informations ne l'ajoutez pas dans les commentaires ...
Alvar

btw, pourquoi avez-vous 32 bits sur cette spécification? Cela n'a aucun sens. Je ne peux pas comprendre votre problème cependant, combien de serveurs différents avez-vous essayé? Cette réponse pourrait vous aider, askubuntu.com/a/44900/10698
Alvar

Réponses:


22

Je l'ai vu aussi.

Je n'ai pas de solution, mais j'ai une solution de contournement ( echo 3 | sudo tee /proc/sys/vm/drop_caches) et potentiellement plus d'informations pour que quelqu'un puisse pousser l'enquête plus loin.

Ce n'est pas un problème de réseau, car dans "Reading package list ..." , il s'agit simplement de lire des fichiers /var/lib/apt/lists/. UNE:

strace -tt -T -fo strace.log apt-get update

donne:

16394 14:43:03.921130 open("/var/lib/apt/lists/gb.archive.ubuntu.com_ubuntu_dists_precise_main_binary-i386_Packages", O_RDONLY|O_LARGEFILE) = 7 <0.000012>
[...]
16394 14:43:03.995238 read(6, "-3.1ubuntu2)\nConflicts: linux86\n"..., 32444) = 32444 <0.000111>
16394 14:43:05.787187 read(6, "c (<< 1:14.b.4-dfsg), erlang-exa"..., 32239) = 32239 <0.000069>
16394 14:43:05.788025 read(6, ".deb\nSize: 42130\nMD5sum: c7de671"..., 31695) = 31695 <0.000068>
16394 14:43:05.870734 read(6, "5: 29c4b395a92bdc12932f151c3643a"..., 31607) = 31607 <0.000071>
16394 14:43:05.890862 read(6, "e-pack-af-base\nFilename: pool/ma"..., 32538) = 32538 <0.000070>
16394 14:43:05.891425 read(6, "buntu-usb-live, ubuntu-dvd-live,"..., 32090) = 32090 <0.000066>
16394 14:43:05.891960 read(6, "cd9755b03ac2c9b8251125c7b6618\nDe"..., 32195) = 32195 <0.000034>
16394 14:43:06.043001 read(6, "rg>\nArchitecture: all\nVersion: 2"..., 32535) = 32535 <0.000072>

Découvrez comment ces 8 readappels système ont pris plus de 2 secondes, même si chaque appel individuel prend moins de 1 ms. En cours d'exécution time apt-get updateou en regardant top, ce processus n'est pas occupé entre ces deux appels. Alors pourquoi le retard?

Ensuite, j'ai fait:

echo t > /proc/sysrq-trigger

à quelques reprises et a examiné le résultat dans kern.log:

 apt-get         D 00000000     0 16790  12706 0x00000000
  e8695d30 00000086 f7bd5e6c 00000000 f7bd5e44 f74a6580 c1990e00 c1990e00
  efe46efe 000042cb f7b9de00 e71a7230 f74a6580 c107e116 00000000 00000000
  044aa200 00000000 00000000 00000000 00000000 e8695d0c e8695d0c c1038de8
 Call Trace:
  [<c107e116>] ? enqueue_entity+0x186/0x220
  [<c1038de8>] ? default_spin_lock_flags+0x8/0x10
  [<c15e13bd>] ? _raw_spin_lock_irqsave+0x2d/0x40
  [<c15e0533>] schedule+0x23/0x60
  [<c15deecf>] schedule_timeout+0x12f/0x290
  [<c1075c38>] ? ttwu_do_activate.constprop.86+0x58/0x70
  [<c1055190>] ? usleep_range+0x40/0x40
  [<c15e0846>] io_schedule_timeout+0x86/0xd0
  [<c15cef7d>] balance_dirty_pages.isra.17+0x3f5/0x4b4
  [<c15e118d>] ? _raw_spin_lock+0xd/0x10
  [<c1180781>] ? __set_page_dirty_buffers+0x81/0xb0
  [<c110deb5>] ? set_page_dirty+0x55/0x60
  [<c11812c9>] ? __block_page_mkwrite+0xe9/0x170
  [<c110f3ae>] balance_dirty_pages_ratelimited_nr+0xde/0x100
  [<c1126f53>] do_wp_page+0x503/0x830
  [<c1128ef7>] handle_pte_fault+0x267/0x2c0
  [<c1129c62>] handle_mm_fault+0x1e2/0x280
  [<c15e4988>] do_page_fault+0x158/0x4c0
  [<c104e4dc>] ? irq_exit+0x5c/0xa0
  [<c15e22d0>] ? do_debug+0x180/0x180
  [<c15e4830>] ? vmalloc_fault+0x195/0x195
  [<c15e1c53>] error_code+0x67/0x6c

Donc, je ne sais pas ce que cela signifie, mais cela concerne la gestion des erreurs de page, donc pointe vers un problème potentiel de gestion de la mémoire.

J'ai ensuite essayé un:

echo 3 >/proc/sys/vm/drop_caches

Et cela a fait disparaître le problème.

Maintenant, cela ressemble beaucoup à un problème de noyau. J'ai donc mis à jour le dernier noyau (backport 3.8 de raring) et c'est là que j'en suis. Mettra à jour si le problème persiste avec le noyau plus récent.

modifier

Le problème persiste avec le nouveau noyau, mais pas aussi mauvais. Et même chose,

echo 3 | sudo tee /proc/sys/vm/drop_caches

efface le problème pendant un certain temps. Je n'ai vu que cela se produire sur les ordinateurs portables MSI (Nom du produit: CR61 2M / CX61 2OC / CX61 2OD).

Modifier décembre 2015

Comme confirmé par btrace aptitude/ apt-getsemble faire des E / S disque à ce moment-là. Il a un fichier temporaire ( /var/cache/apt/pkgcache.bin.<random-chars>) mmappé en mémoire, c'est pourquoi il ne s'affiche pas dans la stracesortie.

Je ne peux toujours pas expliquer pourquoi cela ne se produit que sur certaines machines, pourquoi la suppression des caches aide, pourquoi le passage au 64 bits aide.

Si quelqu'un peut le reproduire, un test intéressant pourrait être de voir si cela se produit également lors de l'exécution sous eatmydataou si le déplacement /var/cache/aptsur tmpfsou un disque virtuel aide.


1
Le 5 avril 2014, je peux confirmer que le problème persiste. Testé sur: Linux Mint 16, 32 bits, fonctionnant sur un processeur 64 bits, Lenovo W520 et: Kubuntu 12.10 32 bits, fonctionnant à nouveau sur du matériel 64 bits, un bureau personnalisé. (et la solution / solution de contournement suggérée ici fonctionne également :))
Ferenc Deak

@fritzone, je me souviens avoir vu le problème signalé ailleurs où les gens disaient que le passage à un système d'exploitation 64 bits a résolu le problème.
Stéphane Chazelas

Je prévois également de revenir à un système d'exploitation 64 bits. Avant, sur le bureau, j'avais une version 64 bits de 12.10 et je n'ai eu aucun problème comme celui-ci.
Ferenc Deak

Le problème existe toujours sur ubuntu 14.04 :-(. Votre solution avec echo 3 à drop_caches a fonctionné. a été tué, cela a laissé des dégâts dans le système, ce qui a totalement ralenti la capacité de lire les paquets
Palo

Je le vois parfois aussi, et la solution de contournement ne fonctionne pas pour moi. Il s'agit d'un système d'exploitation 64 bits ici, sur un ordinateur portable Samsung avec i7 et 8G ram. Seul un redémarrage fait disparaître le problème. Bizarre.
Rmano


4

Suis les étapes:

  • Nettoyer le cache:

    sudo apt-get clean
    
  • Déplacez le sources.listdonc aptne pouvez pas l'utiliser:

    mv /etc/apt/sources.list /etc/apt/sources.list1 && sudo apt-get update
    
  • Déplacez-le puis mettez à jour:

    mv /etc/apt/sources.list1 /etc/apt/sources.list && sudo apt-get update 
    

Vérifiez et supprimez également les PPA et les lignes source dont vous n'avez pas besoin.


1

Sur mon système, la cause était une valeur incorrecte dans la LANGUAGE=variable d'environnement. Il doit contenir des valeurs telles que en:fr:de, et non en_US.UTF-8,sl_SI.UTF-8:

root@fik:~
# locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8,sl_SI.UTF-8
LC_CTYPE=sl_SI.UTF-8
LC_NUMERIC=sl_SI.UTF-8
LC_TIME=sl_SI.UTF-8
LC_COLLATE=sl_SI.UTF-8
LC_MONETARY=sl_SI.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_PAPER=sl_SI.UTF-8
LC_NAME=sl_SI.UTF-8
LC_ADDRESS=sl_SI.UTF-8
LC_TELEPHONE=sl_SI.UTF-8
LC_MEASUREMENT=sl_SI.UTF-8
LC_IDENTIFICATION=sl_SI.UTF-8
LC_ALL=

Lorsqu'elle est exécutée (via strace), la apt-get updatecommande clonks sur l' read()appel. L'exécution prend beaucoup de temps et consomme tous les cycles disponibles d'un cœur de processeur:

root@fik:~
# strace apt-get update
[snip]
read(5, "form, hardware::opengl, implemen"..., 32146) = 32146
read(5, " Maintainers <pkg-bluetooth-main"..., 32658) = 32658
read(5, ": 17569748\nMD5sum: 9c20d52f9a0d5"..., 32200) = 32200
brk(0x55ac79212000)                     = 0x55ac79212000
read(5, "scription-md5: ca1156b27bec24d4c"..., 32469) = 32469
read(5, " Boost.Math Library\nMulti-Arch: "..., 32477) = 32477
read(5, "epends: libc6 (>= 2.4), lsb-base"..., 32648) = 32648
^C--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
strace: Process 18452 detached

Si je mets LANGUAGE=une valeur correcte (telle que en), tout redevient normal:

root@fik:~
# export LANGUAGE=en

root@fik:~
# locale
LANG=en_US.UTF-8
LANGUAGE=en
LC_CTYPE=sl_SI.UTF-8
LC_NUMERIC=sl_SI.UTF-8
LC_TIME=sl_SI.UTF-8
LC_COLLATE=sl_SI.UTF-8
LC_MONETARY=sl_SI.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_PAPER=sl_SI.UTF-8
LC_NAME=sl_SI.UTF-8
LC_ADDRESS=sl_SI.UTF-8
LC_TELEPHONE=sl_SI.UTF-8
LC_MEASUREMENT=sl_SI.UTF-8
LC_IDENTIFICATION=sl_SI.UTF-8
LC_ALL=

root@fik:~
# apt-get update
Hit:1 http://ftp.at.debian.org/debian experimental InRelease
Ign:3 http://ftp.at.debian.org/debian jessie InRelease                                                      
Hit:4 http://ftp.at.debian.org/debian jessie-updates InRelease  
Hit:5 http://ftp.at.debian.org/debian jessie-backports InRelease                                                                             
Hit:6 http://ftp.at.debian.org/debian sid InRelease                                                                    
Hit:7 http://ftp.at.debian.org/debian stretch InRelease                               
Hit:8 http://ftp.at.debian.org/debian stretch-updates InRelease                                             
Hit:9 http://ftp.at.debian.org/debian jessie Release                                  
Hit:2 http://screenshots.getdeb.net xenial-getdeb InRelease                           
Hit:10 http://security.debian.org jessie/updates InRelease      
Hit:11 http://security.debian.org stretch/updates InRelease
Reading package lists... Done 

Oh, et bien sûr, j'ai moi-même mis la valeur incorrecte il y a quelques années. Curieusement, apt fonctionnait parfaitement jusqu'à hier, après la mise à niveau d'apt-get II du système (Debian Sid).
shkitch

J'ai soudain rencontré cela sur une installation 32 bits de Debian Jessie qui fonctionne depuis des années (des décennies?). Rien ne change dans la configuration de la machine, mais cela s'est soudainement produit. Cependant, je n'ai pas LANGUAGE = défini sur quoi que ce soit. Le définir sur "en" ou utiliser C pour toutes les variables locales LC_ * n'a pas encore aidé.
Brad Spencer
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.