Elemzés a Linux kernel több processzormaghoz való skálázódásáról

Kernel

Az MIT számítógépes tudományokkal és mesterséges intelligenciával foglalkozó laborjának, a MIT CSAIL-nek tagjai nemrég egy tanulmányt tettek közzé, amely a Linux kernel skálázódását és annak problémáit vizsgálja a processzormagok számának függvényében. Ahogy a számítógépeinkben egyre több processzormag található, úgy kerül egyre jobban előtérbe ez a problémakör. A problémával foglalkozó kutatók közösségében van egy olyan nézet, amely szerint a tradicionális kerneldizájnok nem skálázódnak jól a többmagos processzorokon. A feltevés szerint, a magok számának növekedésével növekszik az az idő is, melyet az alkalmazások a kernelben töltenek. Elismert kutatók vélik úgy, hogy az operációs rendszerek működésének újragondolásával és újabb kerneldizájnokkal lehetne segíteni a problémán. A tanulmány arra kereste a választ, hogy tradicionális kerneldizájnok felhasználhatók-e és implementálhatók-e oly módon, hogy az alkalmazások megfelelően tudjanak skálázódni.

A hallgatókból, segédprofesszorokból és professzorokból álló csoport hét alkalmazást (Exim, memcached, Apache, PostgreSQL, gmake, Psearchy, and MapReduce) vizsgált meg a kutatás alkalmával egy 48 processzormagot tartalmazó, Linux-ot futtató számítógépen. Arra jutottak, hogy a gmake kivételével az összes alkalmazás skálázódással kapcsolatos problémákba fut az újabb Linux kernelekben. Az alkalmazáscsoportot, amelyet a tesztek alatt használtak, MOSBENCH-nek nevezték el.

A MOSBENCH-ben szereplő alkalmazásokra azért esett a választást, mert azok fel vannak készítve a párhuzamos végrehajtásra és mert a Linux kernel számos nagyobb alrendszerét, összetevőjét igénybe veszik. A Linux kernelre pedig azért, mert tradicionális kerneldizájnra épül és mert a fejlesztőközösség kiváló eredményeket ért már el abban, hogy skálázódóvá tegye. A kutatáshoz a szakemberek a júliusban kiadott 2.6.35-rc5-ös kernelt használták.

A kutatók végül arra jutottak, hogy megfelelő programozási technikák használatával, a Linux kernel kis mértékű - 3 ezer soros - változtatásával a problémás szűk keresztmetszetek eltávolíthatók a kernelből, vagy elkerülhetők ezek a problémák az alkalmazások kis mértékű módosításával.

A kutatás eredményeképpen a fejlesztők 16, a Linux kernel skálázódását javító hozzájárulást - köztük az új elgondoláson alapuló "sloppy counters"-t - készítettek. Emellett publikusan elérhetővé tették a kutatásban használt MOSBENCH csomagot is.

A kutatás nem csak a Linux-szal foglakozó fejlesztők közösségében tarthat számot érdeklődésre. A napokban Andre Oppermann - ismert FreeBSD fejlesztő és commiter - linkelte a tanulmányt a freebsd-hacker és -current listákra. A munkát nagyon érdekesnek nevezte SMP skálázódás témakörben. Nagyon jó olvasmánynak és a FreeBSD jelenlegi SMP skálázódási erőfeszítéseivel erősen összefüggő írásnak nevezte.

A tanulmány elérhető itt.

( apal v | 2010. 10. 03., v – 12:27 )

hat, nem tudom, de:

Arra jutottak, hogy a gmake kivételével az összes alkalmazás skálázódással kapcsolatos problémákba fut az újabb Linux kernelekben

vs.

Exim is a mail server. [...] and forks a new process for each connection, which in turn accepts the incoming mail, queues [...] Each per-connection process also forks twice to deliver [...]

namost akkor ez hogy? a kernel szar vagy a program...? hulyeseg ellen nem sok minden ve'd, es hogy az apriori is hulyeseg, az ellen meg plane. csak igy kicsit hiteltelen/furcsa ez az egesz, meg akkoris ha az alap-problema ketsegtelenul relevans is es erdekes.

( bambano | 2010. 10. 03., v – 12:36 )

Érdekes cikk, én a postgreses részt néztem meg alaposan, és arra jutottam, hogy akik írták, nem olvasták a saját teszteredményeiket. Szerintük a postgres rosszul skálázódik, a saját teszteredményeik szerint meg nem.

nem értelek.
Idézet a tanulmányból:
"For a read-only workload that avoids most application bottlenecks, PostgreSQL spends only 1.5% of its time in the kernel with one core, but this grows to 82% with 48 cores."

A grafikon megnézve is kiderül, hogy kb 6-7 szeresére növelték a PostgreSQL teljesítményét 48 magnál (!) a javasolt változtatásokkal, amit itt éppen kb. 100%-ban a kernel módosítása eredményezett.

A grafikont elnézve az is kiderül, hogy 28 magig nagyjából mérési hibán belül van a különbség a stock kernel+stock pg meg a buherált kernel+buherált pg teljesítménye között. 28-32 mag között hoz valamit, hogy buherált pg-t használnak, stock kernellel, és 32 után letörik a stock kernel.

32 mag alatt jól skálázódik a pg.

ha van egy választási lehetőségünk, ahol
- a két megoldás költsége kb. azonosan nulla
- egy adott cpu számig ugyanazt az eredményt hozzák
- afölött az új megoldás drasztikusan jobb, mint a másik (6 - 7x nagyobb teljesítményt ad Postgresql-nél)

akkor nem kérdés, hogy melyiket kell választani.
Ugye egyetértünk, hogy az új megoldás a jobb?

mivel a két megoldás költsége nem azonosan nulla, hanem az egyiké nagyjából nulla, a másik meg sok milliós tétel, ezért eléggé kérdéses, hogy mit kell választani.
ugye megérted, hogy egy vezetőt nem csak 1000 sor kód költsége izgatja, mert nem csak azt az egy "számlát kell aláírnia"?

De hogy világosan értsd, miről beszélek, kapj elő egy táblázatkezelőt és csinálj egy táblázatot.
az oszlopfejlécek legyenek a következők:
- jelenleg általam postgressel üzemeltetett szerverek darabszáma
- már megrendelt, szállítás alatt levő, postgres futtatása céljából beszerzés alatt álló szerverek darabszáma
- 6-9 hónapon belül megrendelni tervezett, postgres futtatására szolgáló szerverek darabszáma

az első oszlopba pedig írd:
<32 procimag
32-35 procimag
36-39 procimag
40-43 procimag
44-47 procimag
>47 procimag

majd töltsd ki. ezek után a tanulmány alapján írd oda minden sor végére, hogy ha megpatkolják a kernelt a tanulmány szerint, az adott procimag mennyiség esetén mennyit gyorsul a postgres. Ezt súlyozva add össze. Neked mi jött ki?

Lényeg h bele tudtál kötni...
Egyre másra jönnek a csiliárd magos processzorok, és látszik h kezdenek a gyártók belejönni, erre azzal jössz, hogy _neked_ ez a kutatás nulla értéket jelent, mert _te_ nem üzemeltetsz 4x magos szervert.

Nem tudom miért érzel akkora késztetést, hogy megfordítsd a logikát, amikor épp arról szól az egész, hogy amennyiben odaállítanak egy sokmagos csoda elé, hogy migrálj, akkor ne kelljen egyből operációs rendszert is váltani, ha a korábbi megoldásaid linyuxon szaladtak, így a _szoftveres_ megoldás nagyjából ingyenes, Lehet h téged személy szerint már nem fognak ilyen csúf szituációba kergetni, de azért van még pár ember szanaszét a világban, akik most megörültek annak, hogy volt aki vette a fáradtságot, és nemcsak méricskélt, meg publikált egy újabb esszét, hanem viszonylag egyszerű megoldást is adott a problémára.

figyelembe véve, hogy én sehol nem mondtam, hogy ez a kutatás nekem nulla értéket jelent, az derül ki, hogy nem én, hanem ti kötöttetek bele az egészbe. ezen kijelentés cáfolatához linkeld azt, ahol olyat mondtam, hogy ez a tanulmány nekem nulla értékű.

tök frankó lenne, ha a funkcionális analfabéták leszoknának arról, hogy azzal vitatkoznak, amit sikerült kiolvasni a hozzászólásból és nem azzal, ami valójában oda le van írva.

Arra is kíváncsi lennék, csak úgy pletykaszinten, hogy milyen tömegesen veszélyeztet embereket az, hogy 48 magos gépek elé állítják őket postgressel. Az a baj, hogy többször is látszik a véleményeken, hogy kizárólag konzolhuszár szemszögből nézitek a dolgokat, nem pedig összességében. Na mindegy.

Ohh -- azon kívül h ezt otthon légyszíves -- elnézést kérek, ha félreértettem volna azt a két kijelentésedet, hogy kvázi hülyeségnek tituláltad a pgsql-es szekciót, és fantazmagóriának a 4x magos irányú skálázást.

Mondhatnám azt is, hogy "Az a baj, hogy többször is látszik a véleményeden, hogy kizárólag a saját környezeted szemszögéből nézed a dolgokat, nem pedig összességében", de egyáltalán nem a kötekedés volt a célom, pusztán szerettem volna felhívni a figyelmedet arra a problémára, hogy elég szubjektíven állsz a dologhoz. Remélem ez érthetőbb volt...

tisztázzuk:
- azzal, hogy kikotortak egy kernel hibát, engem megvédtek egy (vélhetően) 10 misinél lényegesen nagyobb összegű beruházásba való belebukástól. mert most már tudom, hogy bizonyos vasakon nem megy jól a pg.
- azzal, hogy mindezt helyettem kikotorták, nagy munkától kíméltek meg engem, mondhatom: nekik hála, nem fogok rosszul dönteni.
- fenti két dolog miatt azt mondani, hogy számomra értéktelen volt a tanulmány, hát nem áll erős lábakon
- nem a pgsql szekciót tituláltam hülyeségnek, hanem az általuk levont egyik következtetést.
- ha az, hogy teljes költséget veszek figyelembe, nem részköltséget, szubjektív, akkor szubjektív vagyok.

"A grafikont elnézve az is kiderül, hogy 28 magig nagyjából mérési hibán belül van a különbség a stock kernel+stock pg meg a buherált kernel+buherált pg teljesítménye között. 28-32 mag között hoz valamit, hogy buherált pg-t használnak, stock kernellel, és 32 után letörik a stock kernel.

32 mag alatt jól skálázódik a pg."

viszont a hozzászólásod felmenői között ez is szerepel, ahol pontosítom azt, amit kifogásolsz, ergo erre is válaszoltál most.

Ha jól értelmezem, az MIT CSAIL egy kutató labor, célszerű a publikációikat is ez alapján értelmezni. Őket kevésbé köti az a megközelítés, hogy a kutatásaiknak azonnali haszna legyen, lehetőségük van a szoftver- ill. hardverfejlődés tekintetében távolabbra tekinteni, mint 6-9 hónap.

Ha visszanézünk, volt már olyan trend, hogy minél erősebb processzor; volt már olyan, hogy minden speciális feladat külön célprocesszorra delegálása (pl. lebegőpontos műveletek -> FPU, grafikához vektorműveletek -> GPU); volt már olyan, hogy szekvenciális kódban párhuzamosítható részek automatikus felismerése és részlegesen párhuzamos futtatása. Ma a minél több processzor + szoftveroldali masszív párhuzamosítás a sláger, nem véletlen, hogy a funkcionális nyelvek egyes nyelvi elemeit igyekeznek az átlag programozó értelmi szintjére lebutítva benyomni a mainstream nyelvekbe.

Ha feltesszük, hogy ez a legújabb trend még kitart az évtized végéig, akkor a tanulmány könnyen a "bezzeg mi már mikor megmondtuk, most persze örülnétek ha hallgattatok volna ránk kedves Linus" státuszba kerülhet.

Abban igazad van, hogy a jelenlegi használati esetek nem illeszkednek a kutatási anyagban szereplő problémás esetekre.

összehasonlítva 1-28 mag között a teljesítményt, azt látni, hogy alig-alig csökken a magonként kiszolgált kérések száma +1 mag bevonása esetén. 28-32 mag között van egy pont, amikor drasztikusan romlani kezd.

Szerintem mindenképpen egy árnyaltabb megfogalmazás kellett volna, ami jobban közelíti a mindennapok valóságát.

az egyik egy világvégi portálon egy hozzászólás volt, a másik meg egy tudományos publikációban közölt kutatási eredmény. majd ha árnyaltabb megfogalmazást kívánok írni, akkor én is latexben fogom, 15 grafikonnal, 40 oldalas benyalásjegyzékkel...

de nyugodtan kössél bele, attól lesz több pageview az oldalon:)

A "jó" is egy relatív kategória. Ha ők prezentálnak egy változtatást ami után a régi megoldás egyértelműen rosszabb, bátran mondhatják, hogy az "nem jó".

Ők a saját eredményeikhez viszonyítanak, ez elterjedt a tudományos publikációkban.

Te mihez viszonyítasz amikor azt mondod, hogy a PostgreSQL jól skálázódik? Tényleg a 32+ processzoros rendszerek elterjedtségéhez? ;)

Mert akkor az ő viszonyítási alapjuk sokkal értelmesebb IMHO...

szerintem úgy megy ez, hogy ha B semmilyen esetben sem jobb, mint A, és A bizonyos esetekben jobb, mint B, akkor A jobb, mint B. Még akkor is, ha bizonyos esetekben nem jobb, hanem ugyanolyan.

Szerintem akkor lehet azt mondani, hogy nem egyértelmű, melyik jobb, ha bizonyos esetekben A, más esetekben B a jobb.

G

Eddig én a költségek miatt vitatkoztam, de közben Egerész kiderítette, hogy erre a patchre nem áll fenn, amit írtál.
http://hup.hu/cikkek/20101003/elemzes_a_linux_kernel_tobb_processzormag…

Ha azokon a vasakon, amik jobban el vannak terjedve, rosszabb az új patch, a ritkábbakon egál és a legritkábbakon jobb az új, mint a régi, akkor igencsak nehéz bármit is kijelenteni.

az én becslésem szerint 32 prociig nő az összteljesítmény, mégha csökkenő mértékben is. 32-36 proci között már valamennyit csökken, 36-40 proci között pedig drasztikusan csökken az összteljesítmény.

ez azért becslés, mert arról a grafikonról pontosan megmondani, hogy a 12 procis érték az procinként 20500 vagy 20200 vagy mennyi, nem nagyon lehet.

úgyhogy én azt válaszolom a kérdésedre, hogy a 34. procit már felesleges betenni, N=33.

Ez a 13981239 magos világ tényleg jó, de a magokat "etetni" is kell adattal. Ehhez pedig brutális memória és storage is kell. Az alkalmazás és kernel fejlesztők pedig nem biztos, hogy mindíg 64 core-os tökig rakott teszt rendszereken tudnak minden commit után átfogóan tesztelni. :)

( sz | 2010. 10. 03., v – 12:44 )

Jó látni, hogy a Microsoft Research ilyen elemzéseket is támogat :)

( egeresz | 2010. 10. 03., v – 23:18 )

-szemelyes osszefoglalo-

a linux kernel azokon a vasakon repeszt jol, amik elegge elterjedtek. Nehany igencsak nagy vason mehetne jobban is.

A cikk szerzoi altal eszkozolt modositasok noveltek a 32 mag feletti teljesitmenyt, azonban csokkentettek az 1-2 magnal elerheto teljesitmenyt. A linux modositasainal egyik fontos szempont, hogy "ne legyen roszabb" varhatoan meg reszelni kell a dolgot, hogy ne legen rosszabb 1-2 magnal, de legyen jobb 32 mag felett.

32 mag. 32 onallo vegrehajtasi egyseg.
(A VAX/VMS architekturalis maximalis kepssege (32 bites adatmezon tarolnta a meglevo cpu-maszkot)

15 misi egy ilyen masina, nagyon also hangon. Lesz meg olcsobb is.

Nana. Jó lesz az 10-11 misinek is, hidd el.
És nem rossz gépek ezek. Egyelőre 6 ilyen piheg itt, lötyög rajtuk minden, olyan bikák. De hervasztó tudni, hogy valójában ennél sokkal többre is képesek lehetnének.

Mondjuk mostmár csak az érdekelne, hogy egyes kereskedelmi szoftverek mennyire érzékenyek ugyanerre Linux alatt (pl Oracle db).

van nehany skalazodasi grafikonom, mindenfele hpc alkalmazasra, amik elvileg pont azert vannak, hogy jol skalazodjanak igen sok cpu-ra is; de nem, atlagban ezek szarok, 4 mag felett mar nem latszik erdemi javulas, es addig is csak mintegy 50%.

inkab azt tartom vszinunek, hogy egy enterspajz cucc (mindenestul, nem csak a db) marha rosszul skalazodik.