Kubuntun tuki moniytymisille prosessoreille

[ilkant]

Kun laitoin 4-ytimisen i3 3,1 GHz koneen 8 MB muistilla jauhamaan WGS.bam tiedostosta WGS.fasta -tiedostoa, se vei parisen tuntia tms. aikaa. Levy SATA 3. WGS.bam tiedosto oli kooltaan 73 GB.

Järjestelmänvalvonta näytti, että 8 GB muistista oli vain käytössä 1,6 GB. Eikö olisi nopeuttavaa, jos koko muisti otettaisiin käyttöön? Keskusmuistin ja levyoperaation välillä on 1000 x nopeusero. Liekö Kubuntu-Linuxin skedulointi tuollaisen syynä? Järjestelmän valvontaohjelma kertoi myös, että 2 - 3 ydintä oli lähes 100 % työllistetty, mutta yksi noin 10 % kuormalla. Ilmeisesti se yksi ydin junaili FaceBookia ja odotti käyttäjän näppäilyjä.

BAM oli 73 GB ja fastan kooksi tuli 159 GB. Kun gzippasin fastan, se kutistui 15 GB kokoiseksi. Aikaa meni nelisen tuntia. Tässäkin voisi aikaa kulua vähemmän, jos kaikki 8 GB muistia olisi käytössä? Muistan vuosien takaa, että prosessorin muistihaku verrattuna levyn muistihakuun on 1000 x nopeampi.

WGS on koko genomin testin tulostiedosto. Ja aloin jo suunnitella Ryzen-koneen rakentamista...

[nm]

Järjestelmänvalvonta ei näytä levyvälimuistin osuutta toisin kuin vaikkapa free-komento päätteessä. Kerneli käyttää kyllä vapaata muistia (yleensä suurimman osan siitä) levyoperaatioiden puskurointiin. Esimerkiksi minulla on 16 Gt muistia, josta parhaillaan eri sovellusten ja prosessien käytössä 11 Gt, ja vapaasta reilun 5 gigan osuudesta 4,9 Gt on freen mukaan levyvälimuistina.

Ytimien kuormituksen osalta taas riippuu täysin sovelluksesta ja laskenta-algoritmeista, kuinka hyvin rinnakkaislaskentaa voidaan hyödyntää. Mitä sovellusta käytit laskentaan, ja millaisin asetuksin?

Jos jokin laskenta ei sinänsä rinnakkaistu, joskus voi olla hyödyllistä ajaa sitä usealle erilliselle datajoukolle rinnakkain eri prosesseissa.

[Postimies]

Hitaalla levyllä RAM-levy auttaa, mutta noin isoja tiedostoja ei sinne mahdu. Nopeusetu vaikka C-käännöksessä ei sentään 1000x ole, mutta merkittävä. Voit kokeilla vaikka kauanko kerneli kääntyy RAM-levyllä. Itsellä alle 10 min. Pakkauksessa gzip hyvä valinta nopeuden suhteen.  Bzip2 tai XZ pakkaa paremmin, mutta kestää kauemmin.  Bzip2 muistaakseni osaa hyvin käyttää useampaa ydintä. Ison tiedoston pakkaus kestää - entä jos työn jakaisi osiin? Jakaisi tiedoston 1G palasiksi ja lykkäisi työn RAM-levylle.

[retu]

Nuo gzip ja bzip ovat kyllä yleisiä ja paljon käytettyjä ohjelmia ja ovat olleet pitkään olemassa (=luotettavia ja koeteltuja ohjelmia). Minusta ne ovat silti tekniikaltaan hieman vanhentuneita ja siksi suoraan sanoen hieman ärsyttää, kun niitä aina tuputetaan. Muistaakseni gzip käyttää samaa lz77 algoritmia kuin alkuperäinen zip-ohjelma (siis kun käyttis oli dos x.x ja ohjelmat olivat 16 bittisiä, muistatteko?). Työpuskuri taitaa olla 64k, joten se ei voi olla kovin tehokas isojen tiedostojen kanssa. On myös hidas (imho), mutta tämä nyt on tietysti suhteellista. Tuo bzip on sitten kyllä parempi pakkaamaan, mutta vielä paljon hitaampi kuin gzip.

Sen sijaan xz käyttää uudempaa lempel-ziv algoritmin sovellusta. Tässä oikeastaan pitäisi kai puhua samaan pakettiin kuuluvasta lzma komennosta, jos halutaan parametreiltaan gzip-ohjelmaa vastaava toiminto. Siinä on oletuksena ~100M puskuri ja tukee myös säikeitä. Pakkaa todella hyvin, mutta toisaalta on myös erittäin hidas.

Nopea pakkausta haluavan kannattaa tutustua lz4-ohjelmaan. Siinä on myös alkuperäisen lz algoritmin uudelleen tuunattu versio, mutta tällä kertaa viilaukset on tehty nopeus edellä. Osaa myös käyttää säikeitä. On huonompi pakkaaja kuin edellä mainitut, mutta kertaluokkaa nopeampi kuin gzip.

Mitä nää nyt sitten tarkoittaa käytännössä?

Riippuu tapauksesta, joten pitää vain kokeilla. Mulla sattui olemaan download hakemistossa Raspianin image-tiedosto, alkuperäinen zip on 1,7Gt, purettuna levy-image on 4,7Gt. Kokeilin pakata sen gzip-ohjelmalla. Tähän meni ~3 minuuttia, tuloksena 1,7Gt tiedosto. Seuraavaksi kokeilin lz4-ohjelmaa, meni ~10s ja tuli 2,2Gt tiedosto. Seuraavaksi lzma (xz), aikaa kului puolisen tuntia, tuloksena 1,3Gt tiedosto. Kun en ole masokisti, niin en jaksanut kokeilla bzip-ohjelmaa (se on todennäköisesti melkein yhtä hidas kuin lzma, mutta huonompi pakkaamaan).

Sekä lz4 että lzma ovat tuunattavissa komentoriviparametrein. Vertailun vuoksi, komento "lz4 -9" teki 2 minuutissa 1,9Gt tiedoston ja "lzma -3" teki 15 minuutissa 1,4Gt tiedoston. "lzma -9" tekisi varmasti pienimmän tiedoston, mutta veisi tunteja (en kokeillut).

[juyli]

Nuo gzip ja bzip ovat kyllä yleisiä ja paljon käytettyjä ohjelmia ja ovat olleet pitkään olemassa (=luotettavia ja koeteltuja ohjelmia). Minusta ne ovat silti tekniikaltaan hieman vanhentuneita ja siksi suoraan sanoen hieman ärsyttää, kun niitä aina tuputetaan.

Luotettavuudesta ja yhteensopivuudesta lienee nimenomaan kyse (kuten esim. LTS-versio tai uusin virallinen julkaisu).
Jotkin jakelut kuten vaikka Slackware on siirtynyt ohjelmalähteissään käyttämään xz-pakkausta. Mutta toki voidaan
laajemminkin spekuloida, onko pakkausteholla tai purkunopeudella suurempaa merkitystä. Erityisesti kun paketit on
tarjolla erilaisille prosessoreille, muistimäärille, arkkitehtuureille ym. Kysymyksessä on siis kompromissi.

Useat varmuuskopiointiohjelmat tarjoavat vaihtoehtoisia tallennusformaatteja - joten kuten yleensäkin Linux-
järjestelmissä on laaja valinnanvapaus. Koskapa esim. varmuustallennuksia yleensä ajetaan tausta-ajoina, ei
ohjelman nopeus ole ainoa kriteeri, vaan esim. käytetty pakkaukseen vaadittava prosessoriteho tai muistimäärä.

[Postimies]

Kokeilin huvikseni kernelin lähdepuuhun - samalla kodi soitti musaa ja selain oli auki

time tar -cjf linux-4.4.146  koe/linux-4.4.146

real   0m57.684s
user   0m57.648s
sys   0m0.884s

Tuolla tuli bzip2 paketti oletuksilla 102,1 Mib

 time tar cf linux-4.4.146.lzma --lzma koe/*
real   4m46.566s
user   4m46.712s
sys   0m2.636s

Tuolla tuli lzma paketti oletuksilla 86,8 Mib

time tar -zcf linux-4.4.146.tar.gz koe/

real   0m19.518s
user   0m18.848s
sys   0m1.052s

Teki gzip paketin 131,5 Mib

koe kansion koko 1,1 G. Kernel.org käyttää xz-pakkausta, mikä lienee hyvä valinta. Kone melko vanha i3 ja tuntui vain yksi ydin olevan käytössä. Kopsasin tiedostot ram-levylle. xz parkkasi parhaiten, mutta käytti aikaa paljon. tar on itselle vieras samoin kuin xz ym. jotka suoraan eivät tue hakemiston pakkausta. Tehokas pakkaus hyvä jos pakettia jaetaan verkossa monelle käyttäille kuten kernelin lähdekoodia. Muuten kai turhaa käyttää sähköä ja aikaa piemmän paketin tekoon jos ei pakottavaa tarvetta. Tietysti voisi kokeilla vielä jolla levykuvalla, mutta ne sisältävät usein valmiiksi pakattua dataa. xz pakkasi läjän tekstitiedostoja melko hyvin. Ehkä sillä voisi saavuttaa 90% pakkaustulos kun lähdekoodissa paljon toistoa.

Kokeilin vielä toisella koneella
time tar -I pbzip2 -cf tarball.tbz linux-4.14.166/

real   0m14,744s
user   1m51,747s
sys   0m5,222s

pbzip2 sisältää tuen monelle ytimelle.
Aika tipahti minuutista noin 15 s.

time  tar -I pxz -cf tarball.txz linux-4.14.166/

real   1m15,276s
user   7m41,184s
sys   0m4,306s

Aika tässäkin parempi.

time  tar -I "pxz -9" -cf tarbal9.txz linux-4.14.166-gentoo/
Mikähän tässä vikana kun ei toiminut. Piti kokeilla parasta pakkaustasoa.

[retu]

Eikö myös ubuntun/debianin deb-paketit ole nykyään xz pakattuja? Kuten tietysti archin ja monen muunkin jakelun paketit.

Tuo xz/lzma tekee pienimmät paketit, muttaa ottaa sitten aikansa. Pakkaan sillä lähinnä isoja tiedostoja, kuten tietokantoja tai levykuvia, koska niissä pakkausteho korostuu. Kestää tietysti aikansa, mutta eihän sitä tarvitse istua vahtimassa.

Sen sijaan lz4 on kehitetty "realiaikaiseen" pakkaukseen. Esimerkiksi zswap ja zram tukevat sitä, sillä ajatuksella että pakkaus muistiin on uusilla prossuilla nopeampaa kuin swappaus levylle.