Das Lesen der Paketliste dauert ewig

Ich habe versucht, meine Inhalte auf meinem Computer zu aktualisieren, und es scheint, dass meine Paketliste nicht gelesen werden kann. Es sieht so aus, als ob ich jedes Mal, wenn ich das mache sudo apt-get install *something* && sudo apt-get update, beim Lesen der Paketliste hängen bleibe, dies war vorher kein Problem. Hier sind meine Spezifikationen und so weiter:

• Speicher: 15,8 gb
• Prozessor: AMD Phenom (tm) II x4 965 Prozessor x 4
• Grafik: Gallium 0.4 auf AMD BARTS
• Betriebssystemtyp: 32-Bit
• Netspeed:

Ich habe das auch gesehen.

Ich habe keine Lösung, aber ich habe eine Problemumgehung ( echo 3 | sudo tee /proc/sys/vm/drop_caches) und möglicherweise mehr Informationen, damit jemand die Untersuchung fortsetzen kann.

Dies ist kein Netzwerkproblem, da unter "Paketliste lesen ..." nur Dateien eingelesen werden /var/lib/apt/lists/. EIN:

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

gibt:

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>

Sehen Sie, wie diese 8 readSystemaufrufe über 2 Sekunden dauerten, obwohl jeder einzelne Anruf weniger als 1 ms dauert. Laufen time apt-get updateoder auf der Suche auf top, ist dieser Prozess zwischen diesen beiden Anrufen nicht besetzt. Warum also die Verzögerung?

Dann habe ich gemacht:

echo t > /proc/sysrq-trigger

ein paar mal und schaute sich das Ergebnis in 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

Ich bin mir also nicht sicher, was das bedeutet, aber das betrifft die Behandlung von Seitenfehlern. Dies weist auf ein potenzielles Speicherverwaltungsproblem hin.

Ich habe dann versucht ein:

echo 3 >/proc/sys/vm/drop_caches

Und das ließ das Problem verschwinden.

Nun sieht es sehr nach einem Kernelproblem aus. Also habe ich auf den neuesten Kernel aktualisiert (3.8 Backport von raring) und das ist, wo ich bin. Wird aktualisiert, wenn das Problem mit dem neueren Kernel weiterhin besteht.

Bearbeiten

Das Problem besteht weiterhin mit dem neuen Kernel, wenn auch nicht so schlimm. Und das Gleiche,

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

löscht das Problem für eine Weile. Ich habe das nur auf MSI-Laptops gesehen (Produktname: CR61 2M / CX61 2OC / CX61 2OD).

Edit Dezember 2015

Wie durch btrace aptitude/ bestätigt apt-get, werden momentan einige Datenträger-E / A-Vorgänge ausgeführt. Es hat eine temporäre Datei ( /var/cache/apt/pkgcache.bin.<random-chars>) im Speicher, weshalb sie in der straceAusgabe nicht angezeigt wird .

Ich kann immer noch nicht erklären, warum dies nur auf einigen Computern der Fall ist, warum das Löschen von Caches hilft und warum das Wechseln auf 64-Bit hilft.

Wenn jemand es reproduzieren kann, könnte ein interessanter Test sein, zu sehen, ob dies auch passiert, wenn er unter eatmydataoder /var/cache/aptauf tmpfseine Ramdisk läuft oder dies hilft.

Der Rat unter http://antti-juhani.kaijanaho.fi/newblog/archives/521 hat mich auf verschiedenen Computern mehrmals beschleunigt:

sudo dpkg --clear-avail
sudo sync-available

(Der Blog hat auch empfohlen, sudo dpkg --forget-old-unavailzwischen den beiden Schritten zu wechseln, aber anscheinend ist er veraltet und wird nicht mehr benötigt.)

Folge den Schritten:

• Cache leeren:

  sudo apt-get clean
  

• Bewegen Sie den sources.listso aptkann es nicht verwenden:

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

• Verschiebe es zurück und aktualisiere:

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

Überprüfen und entfernen Sie auch alle PPAs und Quellleitungen, die Sie nicht benötigen.

Auf meinem System war die Ursache ein falscher Wert in der LANGUAGE=Umgebungsvariablen. Es sollte Werte enthalten wie en:fr:deund nicht 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=

Wenn straceder apt-get updateBefehl ausgeführt wird (über ), klingelt er beim read()Aufruf. Die Ausführung dauert einige Zeit und beansprucht alle verfügbaren Zyklen eines CPU-Kerns:

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

Wenn ich LANGUAGE=einen korrekten Wert einstelle (zB en), wird alles wieder 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