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:
command-line
apt
Dre
la source
la source
sudo apt-get update
, n'est-ce pas?Software Sources
, voyez si la sélection d'un autre serveur, au lieu de votre actuel, aide.Réponses:
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:donne:
Découvrez comment ces 8
read
appels système ont pris plus de 2 secondes, même si chaque appel individuel prend moins de 1 ms. En cours d'exécutiontime apt-get update
ou en regardanttop
, ce processus n'est pas occupé entre ces deux appels. Alors pourquoi le retard?Ensuite, j'ai fait:
à quelques reprises et a examiné le résultat dans
kern.log
: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:
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,
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-get
semble 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 lastrace
sortie.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
eatmydata
ou si le déplacement/var/cache/apt
surtmpfs
ou un disque virtuel aide.la source
Les conseils de http://antti-juhani.kaijanaho.fi/newblog/archives/521 m'ont accéléré plusieurs fois sur divers ordinateurs:
(Le blog a également recommandé
sudo dpkg --forget-old-unavail
entre les 2 étapes, mais apparemment, il est obsolète et n'est plus nécessaire.)la source
Suis les étapes:
Nettoyer le cache:
Déplacez le
sources.list
doncapt
ne pouvez pas l'utiliser:Déplacez-le puis mettez à jour:
Vérifiez et supprimez également les PPA et les lignes source dont vous n'avez pas besoin.
la source
Sur mon système, la cause était une valeur incorrecte dans la
LANGUAGE=
variable d'environnement. Il doit contenir des valeurs telles queen:fr:de
, et nonen_US.UTF-8,sl_SI.UTF-8
:Lorsqu'elle est exécutée (via
strace
), laapt-get update
commande clonks sur l'read()
appel. L'exécution prend beaucoup de temps et consomme tous les cycles disponibles d'un cœur de processeur:Si je mets
LANGUAGE=
une valeur correcte (telle queen
), tout redevient normal:la source