SMP tömörítő program Linux alatt?

 ( sheridan | 2011. február 25., péntek - 11:32 )

Sziasztok!

A RAR programot nagyon szeretem, az egyik (ha nem a legjobb) tömörítőnek tartom. A WinRAR verziója (és Win alatt a CLI is) képes több processzormagot használni, de a Linuxos cli verziót eddig nem tudtam erre rávenni.

Milyen tömörítő programot ismertek Linux alá, ami tud nagyobb tömörített fájlokat kezelni oda-vissza, és nem jön zavarba 10-20+ CPU-tól? Vagy csak álmodozom...?

Próbáltam ezeket: PBZIP2, MGZIP, LZOP... De a RAR tömörítési rátáját valamiért nem közelítették meg az én tesztjeimen, jóllehet ezek tudnak SMP-t és sokprocesszoros gépen összehasonlíthatatlanul gyorsabbak, mint a Linuxos RAR cli. Kár. Van esetleg jobb alternatíva?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

bzip2? gzip?
Ha jót akarsz, akkor ne használj rar-t, azt te csak hiszed, hogy a legjobb, nem az. Alapvető problémák vannak vele, pl nem lehet streamelni (merthogy nem adaptív az algoritmusa), és ha egy file is sérült, akkor az összes tömörített adatodat bukod, nem tud részleges kicsomagolást.

Hm. Csúnyán hangzik...

Amúgy eddig hasonlóan használtam:

/bin/nice /bin/tar cvpsS /var/epsilon | /bin/nice /usr/local/bin/rar a -m5 -siguestdata.tar -y guestdata

Csak ugye ez is csak 1 CPU-t használ... Amúgy ha recovery recordot adsz hozzá, az növeli a biztonságot, csak épp meglövi a tömörítés értékét.

De mivel nem tud SMP-t, ezért mostmár nem fenyeget az a veszély, hogy tovább használjam...

"Stock" gzip / bzip2 már SMP-aware?? Ezt nem tudtam, ennek utánanézek, Google...

Up: Hát annyit látok Google-zés alapján, hogy vannak implementációi mindkettőnek amik tudnak SMP-t, de ha csak "bepötyögöm" egy mai stock disztróba, hogy gzip stb az nem lesz SMP... Kár. :-(

pbzip2 hasznal smpt

Nem tudom, hogy pontosan mi a nem jo alatta, de szemely szerint nekem is bevalt, szeretem.
Nehany sor a sugobol:

kb            Keep broken extracted files
rr[N]         Add data recovery record

A streameles alatt mit ertesz? Mire hasznalnad?

p             Print file to stdout

Reszleges kicsomagolas:
<@listfiles...>

---
Lehet, hogy kívül szőke vagyok, de belül sötét, oké?!

"A streameles alatt mit ertesz? Mire hasznalnad?"
Azt, hogy még csorog lefele a file a zinternetről, és közben elkezdeném kicsomagolni. Ez csont nélkül megy bzip2-vel és gzip-el is, rar-al még sosem sikerült, mindig meg kellett várni, míg leér a teljes/összes darab. Bár az is igaz, hogy az utóbbi 1-2 évben nem használtam egyáltalán, lehet azóta sikerült rendes bufferelést implementálniuk bele.

Lehet hogy a zip-hez hasonlóan a végén van valami fontos információ, ami nélkül csak tétován nézegeti, hogy most mi legyen.

amig nincs meg minden, nem tudja kiszamitani az egesz archivra ervenyes crc -t.

Mivel nincsen TV-m, ezert egyes sorozatokat egyeb forrasokbol szoktam beszerezni, amik jellemzoen rar-olva vannak. Ebben az esetben tokeletesen mukodik, hogy letoltom az elso file-t, elkezdem nezni, kozben a hatterben toltodnek a tovabbi darabok.
Pl: /usr/local/bin/rar p -inul elsorar.rar | mplayer -

Szerk.
Egyeb teruleten nem hasznalom a 'stream'-elest.

---
Lehet, hogy kívül szőke vagyok, de belül sötét, oké?!

kb. amiota letezik a rar, lehet recovery recordot + recovery particiot adni a tomoritett allomanyhoz. de ha nincs, akkor is hajlando reparalni a serult archivot.
ha igazan biztonsagos tomorito kell, akkor bizony nagyon jo a rar.

ha igazan biztonsagos tomorito kell, akkor bizony nagyon jo a rar.

Egyetértek, de azért itt szószátyárkodtam egy kicsit: http://hup.hu/node/99923

"azt te csak hiszed, hogy a legjobb, nem az"

de, az...

"ha egy file is sérült, akkor az összes tömörített adatodat bukod"

marhaság

"nem tud részleges kicsomagolást"

marhaság

"ha egy file is sérült, akkor az összes tömörített adatodat bukod"

kollega arra gondolhat, ha solid vagy mellik archive modot valasztod, azt regebben tenyleg nem lehetett reparalni, ujabbakban nemtudom hogy van, sose volt ra szukseg, leszoktam arrol a modrol.

Solid archive módban sem lesz semmi baja, gyakorlatilag ugyanaz érvényes rá mint a nem-solid módra. Adsz rá 1, max 3% recovery recordot, akkor szinte bármilyen hibát helyrerak ami transzfer miatt keletkezett, de akár kisebb csonkolásokat is (utóbbiakat persze ésszerű keretek között). Ezért szerettem nagyon, és szeretném még most is, ha tudna SMP-t Linux alatt...

Csak azért merem ezt így kijelenteni, mert jártam így anno és akkor nagyon jól jött ez a képessége (tömörített .sql adatot több helyütt keletkezett transzferhiba után RR alapján visszaállított helyesen)... amúgy isten ments, hogy még egyszer ki kelljen próbálnom...

p7zip, lbzip, lzma

Egyébként lacos fórumtárs írt ilyen párhuzamos tömörítőket.

--
falura elmegy, városban meg úgy sem nézik...

Megnézem még ma, köszi!!

Én a (p)7zip-el kezdeném, jelenleg jobbat nem ismerek.

+1

Megtanult már nem elcseszni a jogosultságokat vagy még mindig tar-ozni kell előtte?
--
Solaris Express
Opera

A pigz többszálas és otthoni körülmények közt 4 magon elég meggyőzően működik, a tömörítés mértéke állítható 1-9 közt, a rart viszont szerintem nem ismeri.

Annyi baj legyen; nem feltétel, hogy kibontsa a régi backupokat, csak, hogy tudjon sok gigát kezelni és SMP legyen... Kis szerencsével úgysem lesz rájuk (mármint a RAR-os bkp-kra) szükség, ha meg igen, ott a régi RAR. :-) Meglátom, hogy illeszkedik ez is a képbe... köszi!

Epelből felraktam a p7zip-et (4.61 beta) és délután kísérletezgettem vele. Azt látom, hogy ez már lényegesen gyorsabban tömörít max beállításon is, mint a RAR, és a ráta is elfogadható, de... Van 24 core amit ki kellene használnia, de az összevont CPU terheltség tömörítés közben mindössze 8-11% (hozzáteszem, azért ez valamivel jobb, mint a RAR max 3%-a). Ennél jobb kihasználtságot szeretnék.

Eddig ez a formátum hozta a legjobb teljesítményt:

tar cvpsS /RSYNCROOT/SERVERS/TRINITY | 7za a -mx=9 -ms=on -si trinity.tar.7z

Nézelődöm még a többinél, hátha...

Általában nem a CPU, hanem az I/O a korlátod. Adhatsz neki sokezer magot, ha nem tudod eléggé gyorsan adni a CPUnak az információt, akkor állni fog.

Jogos és általában igaz is... de itt az IOWAIT valahol 0.1-0.2 között ingázik tömörítés közben "top" alapján. :-( Nem tudom, de szvsz nem ez a baj :-( (diszkek: 6xSAS 15K RPM 500G, RAID5)

iotop és iostat mit mond?

iostat a fenti parancs futása közben (rávártam jó 10 percet):

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.58   66.19    2.52    0.18    0.00   29.53

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
cciss/c0d0        0.00         0.01         0.00       3390        234
cciss/c0d0p1      0.00         0.00         0.00       2542        234
cciss/c0d0p2      0.00         0.00         0.00        584          0
cciss/c0d1      320.37     13051.15     17201.87 7637445100 10066416631
cciss/c0d1p1    320.37     13051.15     17201.87 7637444804 10066416631
dm-0             15.00        25.87       106.42   15141298   62275488
dm-1              6.89         0.03        55.06      17610   32221552
dm-2           1370.73        13.09     10964.00    7659162 6416056640
dm-3              7.59        81.09        49.84   47455722   29166664
dm-4              0.00         0.01         0.01       8136       7472
dm-5            182.14     12931.05      6026.54 7567162508 3526688815

iotop sajnos most nem fut:

iotop requires kernel-2.6.18-199.el5 or later, but kernel-2.6.18-194.32.1.el5 is running

Kernel frissítést pedig most biztosan nem csinálhatok :-(

Update: megismételve sem változik

linket nem tudok adni, de azt olvastam, hogy (p)7zip nem skálázódik megfelelően. feljebb írta Polesz, lbzip2 jó lehet, itt láthatsz teszt eredményt.

én lbzip2-t használom ha a tömörítés mértéke a lényeg, és pigz-et ha a sebesség.

Köszi, most ezek jönnek akkor :-)

meg még lényeges szerintem - ahogy olvasható az infóban - hogy kicsomagolásnál is több szálon dolgozik.

Asszem megvan a nyertesünk!!!

PBZIP2 - 96%-os összesített CPU kihasználtság mellett kb. 15 perc alatt benyalta egy komplett szerver backupját, a RAR-nak ehhez órák kellettek ugyanezen a gépen!!!! A ráta is nagyon jó.

Millió köszi!!! :-D

Szerk: A parancs ez volt: tar cvpsSf trinity.tar.bz2 --use-compress-prog=pbzip2 TRINITY/

Update:

Akit esetleg érdekel és hasonló cipőben jár a jövőben, annak írom.

Miután sikerült megoldani (lásd fentebb) az SMP tömörítés kérdését, újabb gond merült fel - történetesen kialakult egy kisebb IO bottleneck, ezért volt csak 95-96% max a CPU kihasználtság.

Az alábbi beállításokkal ezt sikerült megszüntetni, illetve minimalizálni, így mostmár 99-100%-os CPU használat mellett 10-11 perc alatt végez a tesztként használt backuppal a gép, az eddigi 15-16 perc helyett, ami egy backupnál nem sok, (de kb. 25-nél már azért számít):

XFS mount opciók: defaults,noatime,nodiratime,logbsize=131072,nosuid,noexec,logbufs=8

(a nosuid és noexec biztonsági és NEM tuning opció így akinek nem kell, elhagyható)

IO tuning - readahead:
/sbin/blockdev --setra 16384 /dev/cciss/c0d1

IO tuning - scheduler:
echo "noop" > /sys/block/cciss\!c0d1/queue/scheduler

(na, most ezt azért, mert jó RAID controllerünk van, így hadd foglalkozzon az az IO logikával... CFQ és egyéb beállítások jók ugyan, de _ebben a helyzetben_ ez jobb eredményeket hozott. Ez van.)

Remélem valakinek segít...

Bye

A noop helyett jobb lenne a deadline, mert a noop nem vonja össze az egyébként összevonható kéréseket, hamarabb betelik a kontroller CQ-ja. Egyébként szerintem a readahead növelése dobott nagyot, nem..?

Hm. Lehet, mondjuk 8000 körül volt, feltoltam 16000-re... elképzelhető.

CFQ-t, Antic.-t és NOOP-ot használtam eddig, CFQ/Antic. ha nincs normális vezérlő, NOOP ha van. Tmit? Megpróbálom a Deadline-t, úgyis csak arról tudok mit mondani, amit már próbáltam. Holnapra kiderül! Köszi a tippet, érdekes kísérlet lesz :-) Majd jelentek ;-)

dap: nagyon köszönöm az ötletet. Úgy látszik, ez átlag két percet javított az egyes backupok átlagidején, sőt, 15-20%-kal csökkentette az IOWAIT-et. Zseniális.

Na még egy kis tuning volt ma este. Még 1 percet lefaragtam átlagban a backupokon. És csökkent a rendszer reakcióideje IO terhelés alatt.

Akit érdekel:

echo "deadline" > /sys/block/cciss\!c0d1/queue/scheduler
echo "deadline" > /sys/block/cciss\!c0d0/queue/scheduler
/sbin/blockdev --setra 8192 /dev/cciss/c0d1
/sbin/blockdev --setra 8192 /dev/cciss/c0d0
/sbin/blockdev --setra 8192 /dev/VolGroup00/SERVERDATA
echo "8192" > /sys/block/cciss\!c0d1/queue/read_ahead_kb
echo "8192" > /sys/block/cciss\!c0d0/queue/read_ahead_kb
echo "4096" > /sys/block/cciss\!c0d1/queue/max_sectors_kb
echo "4096" > /sys/block/cciss\!c0d0/queue/max_sectors_kb
echo "256" > /sys/block/cciss\!c0d0/queue/nr_requests
echo "256" > /sys/block/cciss\!c0d1/queue/nr_requests

Azt nem garantálom, hogy másnál ez mit eredményez... de nálam bejött...

Jó éjt mára...

subscribe
Elkezdek en is kiserletezni alkalomadtan (eddig huyle voltam, aszittem, ha beleforgatom a kernelbe a default io schedulert, azt csak ujraforditassal tudom modositani..)

--
http://www.micros~1

Úgy néz ki, lehet...

Csak nem tudtam aludni. Egy kis piszkálódás után találtam egy olyan eredményt ami még jobb válaszidőt ad, de a teljesítmény - a látható különbségek ellenére - nem csökken jelentősen:

echo "deadline" > /sys/block/cciss\!c0d1/queue/scheduler
echo "deadline" > /sys/block/cciss\!c0d0/queue/scheduler
/sbin/blockdev --setra 16384 /dev/cciss/c0d1
/sbin/blockdev --setra 16384 /dev/cciss/c0d0
/sbin/blockdev --setra 16384 /dev/VolGroup00/SERVERDATA
echo "8192" > /sys/block/cciss\!c0d1/queue/read_ahead_kb
echo "8192" > /sys/block/cciss\!c0d0/queue/read_ahead_kb
echo "128" > /sys/block/cciss\!c0d1/queue/max_sectors_kb
echo "128" > /sys/block/cciss\!c0d0/queue/max_sectors_kb
echo "1024" > /sys/block/cciss\!c0d0/queue/nr_requests
echo "1024" > /sys/block/cciss\!c0d1/queue/nr_requests
echo "0" > /sys/devices/pci0000\:00/0000\:00\:01.0/0000\:05\:00.0/cciss0/c0d1/block/cciss\!c0d1/queue/iosched/front_merges
echo "0" > /sys/devices/pci0000\:00/0000\:00\:01.0/0000\:05\:00.0/cciss0/c0d0/block/cciss\!c0d0/queue/iosched/front_merges

Ennek az az érdekessége, hogy kikapcsolom benne a front_merges-t, ami úgy tűnik erőforrás felszabadulást eredményez nem szekvenciális IO esetén, egy kis teljesítménycsökkenés árán, ha vannak olyan blokkok, amiket össze lehetne pakolni... cserébe azt az időt másra fordíthatja a gép ha nagy a terhelés. Gondolom.

Aki esetleg próbálkozik, szeretném óvatosságra inteni:

Összvissz hat óra masszív tuning, bonnie++, egyebek és mindenféle /sys alatti cucc babrálása után a Fedora 14 stock kernel feladta NMI-vel. Utána már csak ILO 3 -> reset... Szóval óvatosan, radikálisabb változtatások vagy hosszabb cs***sztetés után időnként úgy látom, nem árt újraindítani, nehogy besokalljon... Jobb ez, mint az fsck, pláne ha XFS...

Gond van...

Ma reggelre észrevettem, hogy a fenti beállítások igen nagy memória használati gondokat okoznak. Számos futó alkalmazás elkezdett őrülten swappelni, az egész rendszer belassult, de az IO műveletek brutálisan gyorsak maradtak.

Ezt nézzétek:

[root@sheridan]# free -m -t -o
             total       used       free     shared    buffers     cached
Mem:         12093      10662       1430          0          8         57
Swap:        14335        147      14188
Total:       26429      10810      15619

Semmi buffer alig egy kis cache, még futó alkalmazások nélkül is van swap... és kb 10 giga memória csak úgy "eltűnt".

Na jó mondom ezt a "top" meg a "ps aux" már nem fogja kimutatni. Szóval nézem cat /proc/slabinfo...

HOPPÁ!

...
kmalloc-1024        2597   3712   1024   32    8 : tunables    0    0    0 : slabdata    116    116      0
kmalloc-512         1353   2016    512   32    4 : tunables    0    0    0 : slabdata     63     63      0
kmalloc-256         5388   6656    256   32    2 : tunables    0    0    0 : slabdata    208    208      0
kmalloc-128         4328   5568    128   32    1 : tunables    0    0    0 : slabdata    174    174      0
kmalloc-64        146168518 146168832     64   64    1 : tunables    0    0    0 : slabdata 2283888 2283888      0
kmalloc-32          6521   6528     32  128    1 : tunables    0    0    0 : slabdata     51     51      0
kmalloc-16         14586  14848     16  256    1 : tunables    0    0    0 : slabdata     58     58      0
kmalloc-8          21906  22016      8  512    1 : tunables    0    0    0 : slabdata     43     43      0
kmalloc-192        13355  26292    192   42    2 : tunables    0    0    0 : slabdata    626    626      0
...

Na, mondom k**vaélet... hát itt van a ramom... :-(

Szóval addig játszottam a kernel beállításokkal, míg ez lett a vége. Azt hiszem, kezdem elölről, lépésről-lépésre, és megnézem, melyik beállítás okozza ezt a disznóságot...

Edit: Ezeket fogom most próbálni, mert van egy gyanúm. Még nem mondok semmit majd utána...

echo "deadline" > /sys/block/cciss\!c0d1/queue/scheduler
echo "deadline" > /sys/block/cciss\!c0d0/queue/scheduler
/sbin/blockdev --setra 8192 /dev/cciss/c0d1
/sbin/blockdev --setra 8192 /dev/cciss/c0d0
#/sbin/blockdev --setra 16384 /dev/VolGroup00/SERVERDATA
#echo "8192" > /sys/block/cciss\!c0d1/queue/read_ahead_kb
#echo "8192" > /sys/block/cciss\!c0d0/queue/read_ahead_kb
#echo "128" > /sys/block/cciss\!c0d1/queue/max_sectors_kb
#echo "128" > /sys/block/cciss\!c0d0/queue/max_sectors_kb
echo "256" > /sys/block/cciss\!c0d0/queue/nr_requests
echo "256" > /sys/block/cciss\!c0d1/queue/nr_requests

Na egyelőre jól néz ki... Az IO teljesítmény elfogadható mértékben csökkent csak, ugyanakkor egyelőre nincs nyoma a fenti észbontó anomáliának - egyelőre. De ugye, öt perc alatt semmi nem derül ki. Elindítottam rajta a maradék taskokat is, hadd daráljon. Estére meglátjuk... Ha jó, akkor továbblépünk a tuninggal. Ha nem... We'll see...

Hát nem tudom...

Teljesítmény konstans stabil, kiváló, memóriát sem zabálja (csak a cache, de az normális), viszont a vesémben érzem, hogy ennek nem lesz jó vége... Valami disznóság készül itt...

Az a helyzet ugyanis hogy egész délután jegyzeteltem a kmalloc-64 értékét, ami konstans, folyamatos növekedést produkál, megállás nékül hízik. Igaz szinte csak bájtonként, lassan, övatosan... De már 391560K-nál jár és növekszik. Ha ez ilyen ütemben folytatódik akkor reggelre a memória felét el fogja foglalni.

Ne legyen igazam. Majd jelentem...

Egyéb tekintetben maximálisan meg vagyok elégedve.

Érdekes:

futtatok egy "updatedb"-t, ez úgy tűnik, triggerel egy slab felszabadítást és miután ideiglenesen növekszik a slabok által elfoglalt memória, lassan elkezd azért csökkenni. Cron-ba ezt naponta egyszer és a gond megoldva? Na de nem akarom elkiabálni. Biztosan nincs ilyen szerencsém...

Update: dap kollégának köszönhetően ez megoldva. Folytatom a kísérletezést... :-)

Tetszik ez nekem. (sub)

+1

+1

+1

subscribe
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

Azt hiszem, komoly gondom van. Kellene valami ötlet...

Nézzétek meg légyszi az alábbi "slabtop" outputot:

 Active / Total Objects (% used)    : 9118075 / 9153600 (99.6%)
 Active / Total Slabs (% used)      : 152157 / 152157 (100.0%)
 Active / Total Caches (% used)     : 75 / 94 (79.8%)
 Active / Total Size (% used)       : 704083.01K / 718307.90K (98.0%)
 Minimum / Average / Maximum Object : 0.01K / 0.08K / 11.19K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
8176704 8176427  99%    0.06K 127761       64    511044K kmalloc-64
554814 553957  99%    0.10K  14226       39     56904K buffer_head
 82824  79807  96%    0.55K   2856       29     45696K radix_tree_node
 73836  66062  89%    0.19K   1758       42     14064K dentry
 23940  19264  80%    0.19K    570       42      4560K kmalloc-192
 22016  21908  99%    0.01K     43      512       172K kmalloc-8
 19737  19737 100%    0.08K    387       51      1548K sysfs_dir_cache
......

Itt ami nagyon érdekes az a kmalloc-64.

Ennek az értéke folyamatosan nő, centiről-centire, mindegy mit csinálok. Próbáltam újraindítani az X-et, kilépni-belépni, runlevelet váltani, valamint ilyeneket és ezekhez hasonló trágárságokat is, hogy kikényszerítsek valamiféle reclaimet:

echo 1 > zone_reclaim_mode
echo 150 > vfs_cache_pressure
sync; echo 3 > drop_caches

stb.

Semmi értelme nem volt, a kmalloc-64 meg sem rezzen, komótosan nő tovább. Nagyon olyan, mint valami memory leak vagy hasonló. A tapasztalat alapján ennek az lesz a vége, hogy a programokat elkezdi majd lenyomni swapba és ez az érték addig nő, amíg a kernel fel nem adja.

Ötlet? :-(

FYI: uname -a := "Linux gepard.unixhosting.local 2.6.35.11-83.fc14.x86_64 #1 SMP Mon Feb 7 07:06:44 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux"

Fedora 14-en nekem is jó sok van ezekből, de egyáltalán nem szaporodnak, fixen állnak:

   OBJS  ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
1109824 1105013  99%    0.06K  17341       64     69364K kmalloc-64

A /sys/kernel/slab/kmalloc-64/store_user -t bekapcsolva letárolja, hogy minek a kérésére allokálta a slabot, amit aztán slabinfo.c-vel fel tudsz dolgozni, de mondjuk szerintem egyszerűbb különböző beállításokkal rebootolgatni és megnézni, hogy mi van rá hatással..

Stimm. Ok köszi szépen, megnézem és majd jelzek vissza ha kimerítettem a dolgot.

Megvan a bűnös, köszi a segítséget! :-)

A kernelt slab debug mód bekapcsolásával újra kellett indítani mert addig nem ment amit mondtál, de azzal együtt megtört a jég.

Szóval a szerver "szabadidejében" a fölös kapacitását web node-ként hasznosítja. A vizsgálatok az Apache felé mutattak, először nem értettem mi lehet, mert minden szerver így van konfigolva. Aztán eszembe jutott valami: Apache-ot ezúttal az előtt fordítottam be, mielőtt a GCC update-eket leszedtem volna. A szerveren php+fastcgid+worker konfigban fut az Apache, ezt most az új gcc-vel komplett újrakonfigoltam és újrafordítottam - láss csodát, megszűnt az effektus. :-)

Na, akkor vissza az IO tuninghoz...

Egy ideje nem írtam mert visszajött a memory leak-szerű hiba és azzal küzdök. Már a HP supportot is megjárta a dolog, akik csak a karjukat tárták szét mondván miért nem támogatott oprendszert használok... Na ja... A fentebbi megoldás egy ideig jónak tűnt, de most újból kezdődik a dolog és nincs egyértelmű jelöltem, hogy mi okozza. Már szinte csontig legyomláltam mindent a vanilla kernelből, de továbbra sem... Amíg erre rá nem jövök valahogy... addig IO tuning a legkisebb bajom. Egy magas rendelkezésre állóságúnak tervezett gépet emiatt kétnaponta újra kell indítsak. Naccerű... Ha ez így megy tovább, vissza fogok térni CentOS 5.5-höz, VAGY szétvirtualizálom a gépet, hogy minden "igényt" ki tudjak elégíteni. Na de még mielőtt ezt megcsinálom, talán abból kellene kiindulnom, mi az alapvető különbség a F14 és C5.5 között, mármint ami ezt okozhatja... Meglátjuk. :-(

MEGOLDOTAM !!!! HEUREKA !!!!

Fyi: Ha valaki Fedora 14 + HP ProLiant DL360 G7 X5650 2P vagy hasonló szerver esetén a fentebb többféle módon is leírt memory leak (-szerű) gonddal találkozik, akkor az alábbi két kis kapcsoló grub.conf kernel bejegyzéséhez való hozzáadásával ez az idegesítő dolog kiküszöbölhető:

apm=off acpi=off

Hogy miért akad össze ez a géppel... az már egy teljesen más történet, amire még nem jöttem rá... De a nagy baj elhárult...

Sziasztok!

Kicsit régebbi ez a bejegyzés, de akit érdekel:

Sikerült visszakövetnem a gondot erre a bugreportra. Legalábbis nagyon nagy valószínűséggel. Összefoglalva arról van szó itt, hogy a HP \\SB._OSC metódusa megsérti az ACPI specifikációt. \\SB._OSC a dokumentáció szerint 8 bájtnyi argumentumot fogad, de a valóságban 12 bájtosként próbálja értelmezni a firmware...

Most tesztelem, hogy egy minimalisztikus acpi=ht (hogy legalább a Hyperthreading működjön) is hasra vágja-e a rendszert mint a full ACPI. Ha nem, akkor nekem ez így nagyon jó... Egyszer majd megoldják. Remélem.

Franc... 18 órával az utolsó újraindítás után, a jól ismert memleak ismét kezd kibontakozni. Bár most nem annyira agresszív, így van rá esély, hogy csak túlságosan rémeket akarok látni. Egyszóval még nem konklúzív az eredmény - de attól tartok ennek megint nem lesz jó vége. Megvárom a 24+, esetleg - ha userek felb@szása nélkül bírja addig, akkor - a 48+ órát, addigra már eléggé szépen fog látszani bármilyen leakage.

Ez így nagyon nem OK. Még Hyperthreadinget sem tudok használni Fedora 14-en a méregdrága HP szerveremen anélkül, hogy spontán elkezdene menetelni a Kernel a halálba? 2011... Na jó. Szedjem már össze magam. Hagyjuk. 24-48 óra múlva úgyis biztosra kiderül minden. Addig nincs értelme nyávogni ezen, még kevésbé találgatni... Majd írok... :-(

Muhhhahaha.... :-D :-(((((( (É: Röhögök a nyomoromon)

Nem kellett ennek 24 óra... Délután a srácok megkezdték a szokásos vinyónyíró aktivitásaikat. A slab memory azonnal elkezdett láthatóan hízni, és amikor a "used" memory 6 giga fölé ment, még pont annyi időm maradt, hogy kiléptessek mindenkit, körbetelefonáljak és megakadályozzam az adatvesztést. Úgyhogy grub.conf <-- acpi=off és restart... láss "csodát". Egy órája semmi gyanús és nincs érezhető teljesítményromlás (WTF???)...

Kezd elegem lenni. Olyannyira, hogy várom a Centos 6-ot... Egy próbát megér. Addig meg elvagyok így, hacsak.... addig rá nem jövök valahogy, hogy ezt hogy lehet megoldani.

Csak gondoltam ehhez egy update:

Nem kell betojni attól, hogy nincs Hyperthreading. Ugyanazt hozza a gép vagy jobbat. Csak akkor látszik némi degradáció, amikor nagyon sok (TÉNYLEG nagyon sok) random IO van, és - gondolom - sok interruptot kell kiosztani, amit a scheduler, ha jól olvastam, akkor szét tud szórni a CPU-k közt, amikből így, ha jól értem, minél tőbb van, annál jobb random IO teljesítményed lehet - bizonyos kereteken belül. Ha jól értem.

De, még ha ezt vesszük is és ez így is van: a teszteredmények marginális (1-2%) körüli max romlást hoztak "abszolút random" IO-ban bonnie++ szerint, normál IO és számítások, backup, VM-ek, stb területén pedig (kb. az a munka amire megvettük) még javult (WTF2???) is a HT kikapcsolásával a telejsítmény.

Na de itt álljunk meg egy kicsit: NEM feltétlen a HT kikapcsolása javított a teljesítményen! Erről nem vagyok meggyőződve. Simán felírható a teljesítmény javulás annak a számlájára, (SZVSZ), hogy az ACPI és APM kikapcsolásával megszűnik a memory leak és nem draggel a gép. Úgyhogy... gondolkodom mi a következő lépés, mert meg kell tudnom, hogy mi az igazság. A memleak megszűntetése nélkül azonban nem tudok tovább lépni... Már érzem, hogy ebből előbb-utóbb soruce bújás lesz, hacsak a COS 6 vagy FC15 új kernelkódja nem "orvosolja" ezt a gondot, mert annyira fel***ta az agyam ez a leak hogy le kell vadásznom ha addig élek. Bár ahhoz még SOKAT kell tanulnom, hogy pár dolgot ami ott van megírva, megértsek... (főleg, hogy ahogy így elsőre látom egyesek b***nak kommentelni a kódjaikat...) :-(

No mindegy. Egyelőre vissza melózni... Majd jelentkezem...

Na akkor akit érdekel annak álljon itt a legutóbbi beállítások, eddig ezek hozták a legjobb eredményt. rc.local-ba írtam őket, hogy bootoláskor beállítódjanak...

/sbin/blockdev --setra 8192 /dev/cciss/c0d1
/sbin/blockdev --setra 8192 /dev/cciss/c0d0
/sbin/blockdev --setra 8192 /dev/VolGroup00/SERVERDATA
echo "noop" > /sys/block/cciss\!c0d1/queue/scheduler
echo "noop" > /sys/block/cciss\!c0d0/queue/scheduler
echo "20" > /proc/sys/vm/dirty_background_ratio
echo "4000" > /proc/sys/vm/dirty_expire_centisecs
echo "4000" > /proc/sys/vm/dirty_writeback_centisecs
echo "40" > /proc/sys/vm/dirty_ratio
echo "0" > /proc/sys/vm/overcommit_ratio

Változtattam az XFS partíción is:

xfs_admin -e -j -c 1 /dev/VolGroup00/SERVERDATA

Továbbá XFS beállítások /etc/fstab:

/dev/mapper/VolGroup00-SERVERDATA /SERVERDATA             xfs    defaults,noatime,nodiratime,logbsize=256k,nobarrier,nosuid,noexec,logbufs=8        1 2

Nyugodalmas, szép jó éjszakát mindenkinek!

Habár azt vártam, hogy a megbeszéltek alapján random IO esetén a noop rosszabb lesz - nem így lett. Fentebbiek után úgy tűnt, hogy a deadline jobb eredményeket hoz, de kiderült, hogy ha random IO és emellett komolyabb terhelés és 10-25 futó alkalmazás, 10K+ nyitott fájl leíró van, akkor a noop nagy könnyebbséget hoz a rendszernek P400i kontrollernél ebben a környezetben. Az alkalmazások válaszideje csökken és kevesebb a "burst" szerű IO ami blokk effektust hozhat létre.

Most nekiállok a max_sectors_kb és "társai" optimalizálásának, mert azt olvastam, hogy ezzel is el lehet érni jobb hatásfokot. Majd közlöm mire jutottam...

Full random IO esetén a noop a legjobb. A deadline akkor jó, ha már szekvenciális IO is van.

Azt érzem, hogy neked egy mindenes szervered van és azzal kínlódsz, hogy nincsenek izolálva az erőforrások a különböző workloadok alá. Mer'ugye, ha a gépnek állandóan változik a workloadja (pl. nappal web kisképekkel, este ftpre töltenek, hajnalban backup és az adatbázisa futtat batch feldolgozásokat, néha kitesznek webre egy videót, stb) és nincsenek izolálva az erőforrások, akkor nehéz úgy optimalizálni, hogy egyiknek se legyen hátrányos, ami jó az egyiknek, rossz a másiknak.

Ha csúcsra akarod vinni az optimalizációt, akkor először izolálni kell a különböző workloadokat úgy, hogy pl külön winyóra/particióra kerülnek a fájljai, beveted a cgroups VM/IO korlátokat, néhol érdemes lehet fadvise()-t rakni az alkalmazásokba (ha natívan nem tudja, akkor LD_PRELOAD-al) vagy extrém esetben jöhet a virtualizáció is.

Amíg nincs egy tiszta, állandó workload, addig az optimalizáció csak szenvedés és rengeteg kudarcba fulladt próbálkozás.

/napibölcselet ;)

Ami a workload-ot illeti, teljesen jól érzed a dolgot :-)

Most adtál egy ötletet. Három részre fogom szedni a nagy /SERVERDATA partíciót. Egy /SERVERDATA/SCIENCE partícióra, amin a kísérleti dolgok mehetnek, egy /SERVERDATA/WEBDATA ami a webszerver funkciókra van optimalizálva, valamint egy /SERVERDATA/BACKUPROOT ami a backup feladatokra a legjobb.

De az az érzésem, hogy ez sem lesz elég. Már XEN-ben kezdek gondolkodni, mert ahhoz, hogy igazán optimális legyen minden, három különböző kernelt kellene fordítanom és futtatnom... De első körben nem megyek ennyire messzire, megpróbálom a fentebbi módszerrel. Ez már tegnap este eldőlt, csak lelkierőm nem volt ahhoz eddig, hogy hozzákezdjek... :)

De magamat ismerve a kíváncsiságom miatt ÚGYIS ki fogom próbálni azt is, hogy három különböző virtuális gép, háromféle kernellel, háromféle optimalizálással, egy kontrolleren, ugyanazon a gépen... Meglátjuk, melyik lesz jobb...

UPDATE: vSpehere/ESX-re gondoltam inkább XEN helyett. Miért? Egyelőre semmi különös - csak a ESX-hez jobban értek. De... ajjaj... már érzem, hogy ebből is az lesz, hogy addig nem fogok tudni nyugodni, amíg a kettőt (XEN vs. VMWare) össze nem hasonlítom és szét nem tuningolom hogy rájöjjek melyikből tudok többek kihozni... Na sebaj. Legalább zajlik az élet... Panaszra nincs okom, egy ilyen szerverrel öröm szórakozni, komolyan, imádom!

Az I/O a szuknek nevezett keresztmetszet, es erre meg egy virtualizacios reteget raepiteni, nonsense. #@!$$


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Van benne igazság de azért kipróbálni nem bűn. Főleg, mert durván kíváncsi vagyok, mi sül ki belőle. Max lesz belőle egy hatalmas BUMP. Na, de itt a hosszú hétvége + új a játék... Van idő, most nem b>>>tat senki, tudok kísérletezni...

Asszem inkább írok erről egy blogot... mert ez így nagyon ciki.

Ha valakit majd érdekelnek a szerencsétlenkedéseim az IO és egyéb tuning területén, ott majd megtalálja egyben.

Köszönöm a figyelmet és a segítséget mindenkinek, aki hozzájárult a threadhez!

Azért utolsó bejegyzésként egy linket arra a blogodra tegyél ide.

Attól, hogy nem szól hozzá egy ideje senki, nem azt jelenti, hogy nem is olvassák (pl.: én :)).

+1

Okok nem is úgy értettem.

Persze mindenképpen be fogom ide linkelni. Tényleg nagyon örülök, hogy van akit érdekel a téma. Hétvégén letisztázok még pár dolgot, csinálok kézzelfogható benchmarkokat, összehasonlításokat, screenshotokat, etc... tesztelni valóm is akad... meg megszerkesztem hogy legyen formája.. Több idő lesz mire elkészül, de ... így csak jobb lesz... :)

+1
Engem is erdekel. Meg ugy is, hoyg a felet nem ertem, nem volt idom utananezni. De sose lehet tudni, mikor fogok neki hasonlonak.

--
http://www.micros~1

Eskü, hogy blogon kívül ez itt az utolsó bejegyzésem de ezt még meg akartam osztani veletek mert... szóval idegesít hogy nincs kinek elmondani...

Legújabb tapasztalat - ha VALAHA gondolkodtok azon, hogy VMWare Workstation 7.x shared folder vagy Samba legyen-e a megoldás Linux hoszt és Windows 2003 guest OS között fájl megosztásra - akkor a mostani teszt alapján nyugodtan mondhatom, hogy a Samba hülyére verte a VMWare nyomorék shared folder rendszerét ha linear throughputról vagy random IO-ról, sok ezer nyitott fájlról vagy szinte bármiről van szó! Lehet, hogy hasznos a VM SF ha gyorsan kell valami pl. áttölteni gyorsan egy printer drivert vagy valami... de... ha permanens és megbízható dolog kell akkor a Samba a jobb... Szerintem.

EDIT: Na, szép jó éjszakát és jó hétvégét mindenkinek!

EDIT 2: Ja bocs, elfelejtettem bepostolni a SMB konfigot. Csak a lényeges rész:

        max open files = 1024000
        log level = 0                      
        socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=8192 SO_RCVBUF=8192
        write raw = yes                    
        max xmit = 65535
        oplocks = yes           
        dead time = 15                     
        getwd cache = yes
        lpq cache = 30

Na, mostmár tényleg jó éjt...

UP: Ez a végleges...

        max open files = 1024000
        log level = 0
        socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=65535 SO_RCVBUF=65535
        write raw = yes
        read size = 65535
        max xmit = 65535
        dead time = 15
        getwd cache = yes

Lehet, hogy kuka kérdés, de mi a helyzet ftp vs samba vonalon?
Azt is lehet csatolni network drive-ként (mármint ftp helyet).

Hm. Thanks! Szöget ütöttél a fejembe... Szeretem ha elgondolkodtatnak... viszont két bajom van vele:

1) Vegyesen Windows (mindenféle Win98(!)-Win7-ig) és Linux (Ubuntu,Mandriva,RHEL,CentOS,Debian) kliens csatlakozik. A Linuxok egyértelmű, de a Winekre nagyon le kell tesztelni mi a tuti, mert egységes megoldás kell, hogy workstation generáláskor ugyanazt tudjuk osztani mindenkinek, nem pedig minden gépre más és ez még csak része az issue-nak.
2) A nagyobbik kérdés: fájlműveletek - ki sem merem mondani - peak akár 400+/sec vagy több, tízezernél is több nyitott fájlleíróval, amit egy 2x1 gbites trunk szolgál ki. Ez még talán nem gond, mert VAN jópár olyan FTP szerver ami röhögve bírja ezt ha jól be van lőve, csak kérdés, hogy CPU/egyéb resource tekintetében melyik az "olcsóbb"? Nem csak szerver, hanem kliens oldalon is, ami nem elhanyagolható, hisz többnyire nincsenek csúcsgépeink sajna. Aztán a "speckó" fájlműveletek, ahol ez a dolog szerintem meg lesz lőve (pl. fájl közepébe beszúrás, egyebek, stb) támogatva vannak-e és ha igen milyen mértékben, stb?

Egyszóval FTPFS-t ilyen load/körülmény alatt egyelőre nem teszteltem. Windows implementációját pedig még kevésbé.

Persze, ez nem jelenti azt, hogy nem érdemes kipróbálni - mert a hangsúly azon van, hogy egyelőre "nem teszteltem". Egyelőre. Szóval köszi az ötletet, beleolvasok a témába... :-)

Az FTP nem blokk alapú, emiatt a "speckó" fájlműveletekre alkalmatlan lesz, ne is töltsd vele az időd. Efféle általános felhasználásra a Samba tökéletes.

Nem blokk alapú... Ok. Akkor sajnos erről ennyit.

Érdekes téma, subscribe.

Ja igen...

Botladozásaim közepette ráakadtam egy rendkívül fontos, ám úgy tűnik, méltatlanul keveset használt és elfeledett tool-ra, amely segít az XFS fájlrendszert rendben tartani. Ő az "xfs_fsr".

Aki esetleg még nem használta - ez a parányi program arra jó, hogy "töredezettség mentesítsük" vele felcsatolt, használatban lévő partíciónkat, jobban mondva javítja a fájlok extentjeinek elhelyezkedését. Na elég a rizsából, lássuk, mit értem el vele:

Na szóval. Ha MOST megnézem a fragmentation factorját az XFS partíciómnak, kb. ezt fogom látni (sajna előtte-utána shot nem készült):

[root@sheridan /]# xfs_db -r /dev/VolGroup00/SERVERDATA
xfs_db> frag
actual 111684, ideal 100781, fragmentation factor 9.76%

Ez egész jó a part. tartalmához képest...

Na, de volt ez úgy, hogy fragmentation factor 92,1! Én hülye meg csodálkoztam, hogy a random IO miért gyatra.

Ekkor ráleltem a neten, hogy van olyan, hogy xfs_fsr. Ezt a programot kétféleképp érdemes szerintem futtatni:

1) CRONTAB

Úgy néz ki, erre lett tervezve és így is érdemes futtatni. Ha paraméterek nélkül indítod el, akkor elkezdi sorra venni a /etc/mtab-ban lévő XFS volume-okat, és végigmegy rajtuk. A státuszát (hogy hol jár) végig a /tmp könyvtárban egy kis fájlban tárolja, így amikor megszakad, tudja, honnan folytassa. A program ebben a módban maximum kb. 2 órát fut, majd a következő futásig leáll és onnan folytatja, ahol abbahagyta.

PITFALL!! A program kemény IO terhelést generál, ezért pár dolgot be érdemes tartani a használatakor (szóltam...):
a) éjjel futtasd vagy akkor amikor nem sok mindenkit zavar, ha a gép leromlik.
b) érdemes IO ütemezőt váltani a futás idejére, így a program a magasan igénybe vett szervereken is kevés kellemetlenséggel futtatható.

Az én "szent grál" beállításom (crontab -e -u root)

0 3,14 * * tue,wed,thu,fri,sat,sun echo "cfq" > /sys/block/cciss\!c0d0/queue/scheduler; echo "cfq" > /sys/block/cciss\!c0d1/queue/scheduler; /bin/nice /usr/sbin/xfs_fsr; echo "noop" > /sys/block/cciss\!c0d0/queue/scheduler; echo "noop" > /sys/block/cciss\!c0d1/queue/scheduler

Ez annyit csinál, hogy a futtatás előtt az ütemezőt az érintett blokkeszközökön átállítja CFQ-ra. Alapból NOOP hozza nekem a legjobb teljesítményt, de nem akarod megtudni, mi történik, ha ez a kis vacak megindul és elkezdi szétkapni a fragmentált fájlokat NOOP ütemezővel. MySQL elsírja magát azon helyben, userek alig tudnak belépni, még egy MC is öt perc mire bejön, stb... szóval CFQ, ez nálam azt eredményezte, hogy alig veszem észre, hogy fut. Ezután alacsony prioritással elindítom (nice), majd a munka végeztével visszaállítom az ütemezőt. Ennyi.

II) Egyes fájlok, esetleg partíciók kézi "defragmentálása"

A programot természetesen lehet kézzel is futtatni (surprise...). Ilyenkor megadod neki, hogy melyik MOUNT POINT-ot vagy melyik FÁJLT (könyvtárat NEM tud!) kapja szét, és már nézheted is, ahogy dolgozik. A -v kapcsoló ilyenkor szórakoztatóbb eredményt produkál, mint bámulni a semmit BTW...

xfs_fsr -v /SERVERDATA/valami.dat

Az effektív eredmény... Hát csak annyit mondok: átlag IOwait eddig random műveleteknél a csúcson 7.5-15 volt, most 2.1 :-D

Újabb tünettel csökkent a tudatlanságom... Na, sziasztok, have a nice weekend...

EDIT:
Hülyeséget beszélek... persze, hogy tudsz vele könyvtárat defragmentálni!! Csak nem közvetlenül, hanem wrapperrel. Valami ilyesmit kell bevetni és kész:

find /konyvtaram/neve -type f -exec xfs_fsr -vvv "{}" \;

Annyira egyértelmű, hogy eszembe sem jutott, amíg most nem volt rá szükség... Na, mostmár tényleg jó hétvégét!