Dotaz: Pomalé načítání seznamu balíků apt-get update

[dustin]

Zdravím, mohu poprosit místní odborníky o radu?

Instaluji voyage (postavený nad debian jessie) na x86 tenký klient s CF kartou. Načítání seznamu balíků ("Reading package lists...") po apt-get update trvá desítky minut, 0% idle, 99% wait.

Strace ukazuje, že se neustále čte soubor s popisy balíků

root@voyage:~# strace -f -p 3784
Process 3784 attached

read(6, "22f982b5f6d46fa1494e235668\nSHA1:"..., 32351) = 32351
read(6, "n-md5: 9dbf17c52e563a4e5cfa9b080"..., 32459) = 32459
gettimeofday({1453757710, 676141}, NULL) = 0
write(1, "\rReading package lists... 11%\r", 30) = 30
read(6, "d-Size: 338\nMaintainer: Debian G"..., 32726) = 32726
read(6, " plugin\nHomepage: http://www.fus"..., 32370) = 32370
read(6, "on: web\nPriority: optional\nFilen"..., 32281) = 32281
read(6, "eforge\nDescription: FusionForge "..., 31739) = 31739
read(6, "ail\nSection: devel\nPriority: opt"..., 32002) = 32002
read(6, "a53bca3e8c47595645\nSHA256: f95ad"..., 32074) = 32074
read(6, "l\nFilename: pool/main/g/gadminto"..., 32224) = 32224
...

kde 
root@voyage:~# ls -l /proc/3784/fd

lrwx------ 1 root root 64 Jan 25 21:30 0 -> /dev/tty1
lrwx------ 1 root root 64 Jan 25 21:30 1 -> /dev/tty1
lrwx------ 1 root root 64 Jan 25 21:30 2 -> /dev/tty1
l-wx------ 1 root root 64 Jan 25 21:30 3 -> /dev/null
lrwx------ 1 root root 64 Jan 25 21:30 4 -> /var/lib/dpkg/lock
lrwx------ 1 root root 64 Jan 25 21:30 5 -> /var/cache/apt/pkgcache.bin.BN8s5j
lr-x------ 1 root root 64 Jan 25 21:30 6 -> /var/lib/apt/lists/ftp.cz.debian.org_debian_dists_jessie_main_binary-i386_Packages

Tedy fd 6 je /var/lib/apt/lists/ftp.cz.debian.org_debian_dists_jessie_main_binary-i386_Packages

Ten soubor má 30 MB, jeho překopírování na CD kartě trvá několik sekund. Přesto naskakují ty řádky ve strace (co řádek, to přečtených 30kB) velice velice pomalu, v jednotkách sekund.

OK, tak třeba má CF karta nějaký velice špatný přístup. Tedy jsem vyrobil tmpfs ramdisk, celý adresář /var/lib/apt/lists do něj nakopíroval a bindnul jsem jej na zpět:

root@voyage:~# mount
...
tmpfs on /mnt/ramdisk type tmpfs (rw,relatime,size=204800k)
tmpfs on /var/lib/apt/lists type tmpfs (rw,relatime,size=204800k)

Opravdu je to v ramdisku, kopírování tohoto souboru do /dev/null nyní jede 100MB/s

root@voyage:~# dd if=/var/lib/apt/lists/ftp.cz.debian.org_debian_dists_jessie_main_binary-i386_Packages of=/dev/null
65970+1 records in
65970+1 records out
33776741 bytes (34 MB) copied, 0.347766 s, 97.1 MB/s

Žádný zázrak, ale to PC má pomalé DDR1 paměti, 1GHz CPU, rychlost odpovídá.

Ještě jsem si ověřil, že to opravdu je na tmpfs

root@voyage:~# df $(readlink -f /proc/3784/fd/6)
Filesystem     1K-blocks  Used Available Use% Mounted on
tmpfs             204800 57808    146992  29% /var/lib/apt/lists

Přesto apt-get update (samozřejmě po jeho opětovném spuštění) jede pořád stále pomalu, wait je úplně stejný a při "Reading package lists" neustále svítí ledka disku, ač by to tam dle strace nemělo vůbec přistupovat (vypisuje se jen read(6), který je na ramdisku).

Kde by mohl být prosím zakopaný pes? Přijde mi, že apt-get (zřejmě nějaká knihovna) nějak divně pracuje s read syscallem. Tenhle problém lidi řeší už roky, nic kloudného/funkčního/smysluplného jsem nevygooglil.

Předem díky za nápady, co by to mohlo dělat.

---

---

Odpovědi

[dustin]

Nikdo opravdu netuší?

[pepe_]

Je to jen odhad , nebrzdí to spíše cpu ? Disk je potom spíše doprovodný projev ?   Já osobně deaktivuju vše co nepotřebuju (repositáře a i src) odmažu složky a znovu dam apt-get update a pro gui i ten xpain indexer pro hledání v synapticu.  Čím větší repa tím pomalejší databázování a tvorba závislostí.

[pepe_]

sorry 0% idle sem si nevšimnul.

[dustin]

Díky.

V topu má apt-get load 0.nic % CPU, vše visí v tom waiting. Je mi divné proč, když má ty soubory v ramdisku. Jakoby přistupoval pořád k těm na disku a ignoroval bindnutý ramdisk.

[wwww]

Neni mozny, ze by byl problem spis pri ukladani? Apt ma interni databazi a ta bude zrejme ulozena taky nekde na te karte. Nebo swap? Asi bych zkusil pomoci ps sledovat jestli neni nektery proces ve stavu D. Pripadne bych pomoci vmstat zjistoval, kde je aktualni zatez.

[dustin]

Předpokládám, že to ukládání bych viděl ve strace. Tam není nic jiného než postupné pomalinké načítání 30kB bloků read(6...), kde fd=6 je ten seznam balíků.

Swap je vypnutý.

Na to vmstat se mrknu, díky za tip.

Bohužel nainstalovat další monitorovací balík (iotop apod.) je díky tomu zaseknutému apt-get nereálné. Zkusím image nakopírovat na klasický PATA disk (minipc má pata konektor), doinstalovat potřebné balíky a zjistit víc.

[Peter Golis]

Niektoré redukcie na CF neumožňovali DMA prenosy a v PIO to bolo dosť pomalé. Tak isto sa systém spomaľoval ak človek nemal správnu veľkosť sektoru pre FS a zarovnané partície vzhľadom na HW. Nebude to tým?

[dustin]

Jasně, u CF je to zásadní. Dělám na tom doinstalování balíků, aby to šlo změřit.

Nicméně ten seznam je v ramdisku (viz ten mount -o bind) a apt-get je přesto pomalý a ledka disku svítí...

[AraxoN]

Tak připojení klasického IDE disku nakonec pomohlo příčinu najít. Člověk se pořád učí - zápis přes mmap do souboru se ve strace objeví logicky jen v okamžiku zavolání toho mmapu. Takže výroba celé 40MB /var/cache/apt/cache.xxxx se mezi voláními read() čtoucími stažené databáze balíků nikde neprojevovala. Proto ta svítící kontrolka - na IDE disku to bylo jasně slyšet

Takže řešením je mountnout tmpfs na vyčištěné /var/cache/apt a nyní trvá Reading package list i na flešce pár sekund a CPU je 100% zatížené apt-get. Je to jen cache, takže ztráta při vypnutí nijak nevadí.

Díky všem za pomoc.

[R]

Dobre vediet, ze apt-get robi takyto bordel. Uz chapem, preco to je take pomale na slabom HW.