Чтение списка пакетов занимает вечность

Question 1

Я пытался обновить свои материалы на своем компьютере, и кажется, что он не может прочитать мой список пакетов. Кажется, что каждый раз, когда я делаю sudo apt-get install *something* && sudo apt-get update, он застревает при чтении списка пакетов, это не было проблемой раньше. Вот мои характеристики и еще много чего:

Память: 15,8 Гб
Процессор: AMD Phenom (tm) II x4 965 Процессор x 4
Графика: Галлий 0,4 вкл AMD BARTS
Тип ОС: 32-разрядная
Netspeed:

Question 2

Совет на http://antti-juhani.kaijanaho.fi/newblog/archives/521 несколько раз ускорил его для меня на разных компьютерах:

sudo dpkg --clear-avail
sudo sync-available

(Блог также рекомендовал sudo dpkg --forget-old-unavail между двумя шагами, но, видимо, он устарел и больше не нужен.)

Question 3

Question 4

Выполните следующие действия:

Очистите кэш:
```
sudo apt-get clean
```
Переместите sources.list, чтобы apt не мог его использовать :
```
mv /etc/apt/sources.list /etc/apt/sources.list1 && sudo apt-get update
```

Переместите его назад, затем обновите:

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

Также проверьте и удалите все PPA и исходные строки, которые вы не делаете необходимо.

Question 5

Я тоже это видел.

У меня нет решения, но у меня есть обходной путь (echo 3 | sudo tee /proc/sys/vm/drop_caches) и потенциально больше информации, чтобы кто-то мог продолжить расследование.

Это не проблема сети, потому что в «Чтение списка пакетов ...» , это просто чтение файлов в /var/lib/apt/lists/. A:

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

дает:

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>

Посмотрите, как эти 8 read системных вызовов заняли более 2 секунд, даже если каждый отдельный вызов занимает менее 1 мс. Запуская time apt-get update или просматривая top, этот процесс не занят между этими двумя вызовами. Так почему задержка?

Тогда я сделал:

echo t > /proc/sysrq-trigger

несколько раз и посмотрел на результат в 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

Итак, не уверен что это означает, но это относится к обработке ошибок страниц, поэтому указывает на потенциальную проблему управления памятью.

Затем я попробовал:

echo 3 >/proc/sys/vm/drop_caches

И это действительно помогло решить проблему.

Теперь, это очень похоже на проблему с ядром. Итак, я обновился до последнего ядра (3.8 backport из raring) и вот где я нахожусь. Обновится, если проблема не исчезнет с более новым ядром.

Редактировать

Проблема с новым ядром сохраняется, хотя и не так плохо. И то же самое,

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

на некоторое время решает проблему. Я видел только это на ноутбуках MSI (Название продукта: CR61 2M / CX61 2OC / CX61 2OD).

Редактировать декабрь 2015 г.

Как подтверждается в btrace aptitude / apt-get, похоже, в то время выполнялись некоторые операции дискового ввода-вывода. Он получил временный файл (/var/cache/apt/pkgcache.bin.<random-chars>), отображенный в памяти, поэтому он не отображается в выводе strace.

До сих пор не могу объяснить, почему это происходит только на некоторых машинах, почему удаление кешей помогает, почему переключение на 64-битные помогает.

Если кто-то может воспроизвести его, интересным может быть проверка того, происходит ли это и при работе в eatmydata, или если перемещение /var/cache/apt на tmpfs или виртуальный диск помогает.

Question 6

В моей системе причиной было неправильное значение в переменной среды LANGUAGE=. Он должен содержать такие значения, как en:fr:de, а не 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=

При запуске (через strace) команда apt-get update клонируется при вызове read(). Для его выполнения требуются целые годы, и он съедает все доступные циклы одного ядра ЦП:

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

Если установить для LANGUAGE= правильное значение (например, en), все снова вернется к норме :

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

Beni Cherniavsky-Paskin · Answer 1 · 11 February 2013 в 16:03

Совет на http://antti-juhani.kaijanaho.fi/newblog/archives/521 несколько раз ускорил его для меня на разных компьютерах:

sudo dpkg --clear-avail
sudo sync-available

(Блог также рекомендовал sudo dpkg --forget-old-unavail между двумя шагами, но, видимо, он устарел и больше не нужен.)

Aditya · Answer 2 · 11 February 2013 в 16:03

Выполните следующие действия:

Очистите кэш:
```
sudo apt-get clean
```
Переместите sources.list, чтобы apt не мог его использовать :
```
mv /etc/apt/sources.list /etc/apt/sources.list1 && sudo apt-get update
```

Переместите его назад, затем обновите:

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

Также проверьте и удалите все PPA и исходные строки, которые вы не делаете необходимо.

Stéphane Chazelas · Answer 3 · 11 February 2013 в 16:03

Я тоже это видел.

У меня нет решения, но у меня есть обходной путь (echo 3 | sudo tee /proc/sys/vm/drop_caches) и потенциально больше информации, чтобы кто-то мог продолжить расследование.

Это не проблема сети, потому что в «Чтение списка пакетов ...» , это просто чтение файлов в /var/lib/apt/lists/. A:

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

дает:

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>

Посмотрите, как эти 8 read системных вызовов заняли более 2 секунд, даже если каждый отдельный вызов занимает менее 1 мс. Запуская time apt-get update или просматривая top, этот процесс не занят между этими двумя вызовами. Так почему задержка?

Тогда я сделал:

echo t > /proc/sysrq-trigger

несколько раз и посмотрел на результат в 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

Итак, не уверен что это означает, но это относится к обработке ошибок страниц, поэтому указывает на потенциальную проблему управления памятью.

Затем я попробовал:

echo 3 >/proc/sys/vm/drop_caches

И это действительно помогло решить проблему.

Теперь, это очень похоже на проблему с ядром. Итак, я обновился до последнего ядра (3.8 backport из raring) и вот где я нахожусь. Обновится, если проблема не исчезнет с более новым ядром.

Редактировать

Проблема с новым ядром сохраняется, хотя и не так плохо. И то же самое,

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

на некоторое время решает проблему. Я видел только это на ноутбуках MSI (Название продукта: CR61 2M / CX61 2OC / CX61 2OD).

Редактировать декабрь 2015 г.

Как подтверждается в btrace aptitude / apt-get, похоже, в то время выполнялись некоторые операции дискового ввода-вывода. Он получил временный файл (/var/cache/apt/pkgcache.bin.<random-chars>), отображенный в памяти, поэтому он не отображается в выводе strace.

До сих пор не могу объяснить, почему это происходит только на некоторых машинах, почему удаление кешей помогает, почему переключение на 64-битные помогает.

Если кто-то может воспроизвести его, интересным может быть проверка того, происходит ли это и при работе в eatmydata, или если перемещение /var/cache/apt на tmpfs или виртуальный диск помогает.

muru · Answer 4 · 11 February 2013 в 16:03

В моей системе причиной было неправильное значение в переменной среды LANGUAGE=. Он должен содержать такие значения, как en:fr:de, а не 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=

При запуске (через strace) команда apt-get update клонируется при вызове read(). Для его выполнения требуются целые годы, и он съедает все доступные циклы одного ядра ЦП:

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

Если установить для LANGUAGE= правильное значение (например, en), все снова вернется к норме :

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

Чтение списка пакетов занимает вечность

4 ответа

Редактировать

Редактировать декабрь 2015 г.

Другие вопросы по тегам:

Похожие вопросы: