También he visto eso.
No tengo una solución, pero tengo una solución ( echo 3 | sudo tee /proc/sys/vm/drop_caches
) y potencialmente más información para que alguien pueda llevar la investigación más allá.
No es un problema de red porque en "Leer lista de paquetes ..." , solo está leyendo archivos /var/lib/apt/lists/
. UNA:
strace -tt -T -fo strace.log apt-get update
da:
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>
Vea cómo esas 8 read
llamadas al sistema tomaron más de 2 segundos a pesar de que cada llamada individual toma menos de 1 ms. En ejecución time apt-get update
o mirando top
, ese proceso no está ocupado entre esas dos llamadas. Entonces, ¿por qué la demora?
Entonces hice:
echo t > /proc/sysrq-trigger
unas pocas veces y miró el resultado en 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
Entonces, no estoy seguro de lo que eso significa, pero eso se ve sobre el manejo de fallas de página, por lo que apunta a un posible problema de administración de memoria.
Entonces probé un:
echo 3 >/proc/sys/vm/drop_caches
Y eso hizo que el problema desapareciera.
Ahora, se parece mucho a un problema del núcleo. Entonces, me actualicé al último kernel (3.8 backport de raring
) y ahí es donde estoy. Se actualizará si el problema persiste con el kernel más nuevo.
Editar
El problema persiste con el nuevo núcleo, aunque no es tan malo. Y lo mismo
echo 3 | sudo tee /proc/sys/vm/drop_caches
aclara el problema por un tiempo. Solo he visto que eso sucede en las computadoras portátiles MSI (Nombre del producto: CR61 2M / CX61 2OC / CX61 2OD).
Editar diciembre de 2015
Según lo confirmado por btrace
aptitude
/ apt-get
parece hacer algunas E / S de disco en ese momento. Tiene un archivo temporal ( /var/cache/apt/pkgcache.bin.<random-chars>
) mmapped en la memoria, por lo que no se muestra en la strace
salida.
Todavía no puedo explicar por qué solo sucede en algunas máquinas, por qué es útil soltar cachés, por qué es útil cambiar a 64 bits.
Si alguien puede reproducirlo, una prueba interesante podría ser para ver si eso también sucede cuando se ejecuta en eatmydata
o si se mueve /var/cache/apt
hacia tmpfs
o un disco RAM ayuda.
sudo apt-get update
, ¿correcto?