Képtelenek követni a szoftverek a hardverek fejlődését
A processzormagok számának növekedési ütemével hamarosan a szerverszoftverek is képtelenek lépést tartani, figyelmeztet a Gartner. A piackutató cég szerint a vállalatoknak figyelemmel kell kísérniük ezt a tendenciát, és felkészülniük az esetlegesen szükséges lépésekre, mint a platform- vagy szoftverváltások. A fokozódó párhuzamosság több évtizedes tendencia, ennek ellenére a szoftveripar láthatóan kínlódik a jelenséggel, és nem tudja megfelelő ütemben fokozni a szoftverek skálázódását.
Egyre több processzor
A többprocesszoros (SMP, symmetric multiprocessing) felépítés sok mindennek nevezhető, de újnak nem. A legelső implementációk több mint négy évtizedre, a számítástechnika hajnalára vezethetőek vissza. A Burroughs vállalat SMP mainframe-jei már az 1960-as években 8 processzorig skálázódtak, és lényegében az összes későbbi "nagygépes" rendszerarchitektúra számára inspirációt jelentettek. A '90-es években már az összes RISC-szállító kínált többprocesszoros gépeket, sőt az első többprocesszoros asztali gép, egy Sun SPARCstation 10 munkaállomás már 1992-ben négy processzorig skálázódott.
Korábban ez azonban nem jelentett problémát a szoftverek számára, a feldolgozási teljesítményt a processzorfejlesztők ugyanis elsősorban az egyszálú végrehajtás gyorsításával igyekezték fokozni: emelték az órajelet, futószalagosították és szuperskalárrá tették a feldolgozást, növelték a végrehajtóegységek számát, a gyorsítótárak méretét, sebességét, bevezették és csiszolták a dinamikus ütemezési technikákat, az elágazásbecslést és spekulatív végrehajtást. Egy 16-32 szálig jól skálázható szerverkóddal kényelmesen le lehetett fedni a piac túlnyomó többségét, miközben az alkalmazás az újabb és újabb processzorokon egyre gyorsabban futott, ahogyan gyorsult a szálak végrehajtási sebessége. A vevők tipikusan nem vettek egyre nagyobb és nagyobb gépeket, a processzorszám egyfajta piacszegmentációs tényező is volt egyben.
Az egyszálú feldolgozás gyorsítására irányuló erőfeszítések azonban egyre csökkenő hozadékkal szolgáltak a komplexitás és energiafogyasztás növekedéséhez képest. A '90-es évek végén megindultak a többszálú mikroprocesszorok fejlesztései, az első kereskedelmileg sikeres implementáció, az IBM RS64-IV 2000-ben debütált, és két szálat kezelt felváltva, áthidalva a nagy késleltetéssel járó eseményeket, de az 1998-as RS64-II is rendelkezett már ezzel a képességgel. Ezzel megkezdődött az a tendencia, hogy a hardver képességeinek kihasználásához a szoftver párhuzamosságát is növelni kellene, hiába futott "ugyanakkora dobozokon".
Ez a trend ráadásul az új évezredben hirtelen felgyorsult. A 2000-es évek elején a chipek ugyanis elérték az energiaplafont, vagyis a fogyasztás és hődisszipáció ésszerű határait. A chipenkénti feldolgozási teljesítmény növelésének technikái nem fulladtak ki teljesen, de egyre gyökeresebb és agresszívebb mikro- és rendszerarchitekturális fejlesztések váltak szükségessé a teljesítmény jelentős növeléséhez, miközben a miniatürizáció egyre nagyobb tranzisztorbüdzsét adott a tervezőmérnökök kezébe. A válasz szinte adta magát: két processzormagot kell integrálni egyetlen szilíciumra, amivel kvázi megduplázódik a párhuzamosított kódok alatt nyújtott teljesítmény, de egy kiegyensúlyozott rendszerben mindenképpen nagyobb nyereséget hoz magával, mint bármilyen költséges mikroarchitekturális továbbfejlesztés. Az IBM Power4 a világ első kétmagos processzoraként 2001-ben debütált.
Power4 wafer
Mindeközben természetesen nem álltak le a mikro- és rendszerarchitekturális fejlesztések, melyek az egyszálú teljesítmény fokozására irányulnak, amire leginkább az Intel 2006-ban debütált Core, majd a 2007-es IBM Power6 szolgálnak kiváló példákkal. Mindez azonban nem változtat a tényen, hogy a jövőben a processzorok erőforrásainak kiaknázása a szoftveres konkurencia fokozódásával jár együtt. Négy éve jelent meg az első kétmagos x86-os chip, kevesebb mint két évvel, 2006 végére pedig már négy magos processzorok is piacon voltak.
Ez a hardver-szoftver olló sújtja a PC-piacot is, ahol például a 8 utasításszálat kezelő négymagos Nehalem adoptációja a professzionális munkaállomásokra és fejlesztői szoftverekre korlátozódik, az olyan hétköznapi alkalmazások ugyanis, mint egy böngésző, irodai program, médialejátszó vagy végfelhasználóknak szánt multimédiás szerkesztők, egyáltalán nem vagy rossz hatékonysággal párhuzamosítottak -- hiába a bődületes teljesítmény, ha nem megfelelő a kód. Ahogyan az STMicroelectronics egy szoftverménöke, Gabriele Svelto fogalmazott, Moore törvénye valójában azt jelenti a PC-k számára, hogy minden két évben megduplázódik a kihasználatlan erőforrások nagysága. Úgy tűnik, ez a hatás a szervereket is egyre inkább fenyegeti.
Túl sok a processzor
A mai szerverszoftverek legalább egy évtizede többprocesszoros környezetben működnek, így alapvető követelménynek számít a hatékonyan többszálúsított kód. A szálak számának hatékony növelése azonban sok esetben egyáltalán nem automatizálható vagy triviális feladat, így a párhuzamosságnak megvannak a határai, jelenleg jellemzően 64 vagy kevesebb processzornál -- aránylag kevés kód képes több száz processzort igazán kihasználni, hiszen eddig tömegigény sem volt rá. Furcsán hangozhat, de úgy tűnik, ezen a területen a hardver gyorsabban változik a szoftvernél -- pedig a processzorgyártók még vissza is fogják magukat, a szoftverek állapotát és 3-5 éves távon várható fejlődését szem előtt tartva tervezik meg chipjeiket.
A Windows Server 2003 és 2008 például legfeljebb 64 (logikai) processzorig, vagyis hardveres utasításszálig skálázódik, ami már jelenleg is korlátozhatja az olyan felhasználási területeket, ahol szükséges volna egyetlen nagy SMP-rendszerre -- például hatalmas OLTP-adatbázisok futtatásakor. Az IBM kínál például akár 32 foglalatig skálázódó Xeon-rendszereket is, ami a hatmagos Intel Dunnington chipekkel megpakolva 192 processzormagot jelent, de 12 foglalat is már 72 processzort takar.
A Gartner arra figyelmeztet, hogy a processzormagok számának gyors növekedése rövid időn belül súlyos problémát okozhat a szoftveriparnak, a hardver párhuzamossága ugyanis magasan meghaladja majd azt a szintet, mint amelyre a szoftverek tervezői felkészültek. Ez az operációs rendszereket, infrastrukturális és köztesszoftvereket, valamint alkalmazásokat egyaránt érinti. "Ezeknek a [kulcsjelentőségű] szoftvereknek a specifikációit vizsgálva világos, hogy közülük sok kihívásokkal néz szembe már a mai lehetséges hardverkonfigurációk támogatásában, és ezek a kihívások csak növekedni fognak a jövőben" -- mondta el Carl Claunch, a Gartner vezető elemzője. A szoftveripar problémája pedig a hardveriparé is, melynek el kell adnia a számítógépeket, de az ügyfeleké is, melyek problémásnak találhatják egy kulcsalkalmazásuk teljesítményének gazdaságos növelését.
Ezzel az ügyfél, ha teljesítményproblémái vannak, nehéz döntések elé nézhet -- migráljon más operációs rendszerre, próbálja meg optimalizálni az adatbázis működését, vagy térjen át egy magonként nagyobb teljesítményt nyújtó rendszerarchitektúrára, ha van ugyan? Esetleg szeletelje szét az adatbázisát, és építsen klasztert? Míg ezt az IT-csapat megoldja, az adatbázison lógó felhasználók szenvedhetnek, csökkenhet a cég produktivitása.
Ez a szakadék pedig tovább tágul, mikor megérkeznek a következő generációs szerverprocesszorok. Az új, Nehalem-alapú Xeon MP például 8 maggal 16 szimultán szálat kezel, egy négyutas szerverben kimeríti majd a Windows Server 2008 határait, a teljesítmény fokozása érdekében így ki kell majd kapcsolni a HyperThreadinget a foglalatok számának növelésekor, vagyis a vevők nem használhatják ki a hardver minden képességét. Az AMD 2010-ben 12 magos processzort mutat majd be.
A várhatóan 2010-ben debütáló Windows Server 2008 R2 ugyan 256 logikai processzorig tolja ki a határt, ez azonban még mindig csak az operációs rendszer szintjén csökkenti egy időre a problémát -- de mi a helyzet az adatbázis-kezelőkkel, middleware-ekkel, üzleti alkalmazásokkal? A "hirtelen" megugró párhuzamosság ráadásul már a szerverek fizikai konszolidációjával sem kezelhető, a mai hypervisorok többsége ugyanis nem képes 64 processzort sem lekezelni -- a VMware ESX Server 3.5 például 32 logikai hoszt processzort képes átkarolni, a 64 processzor támogatása kísérleti stádiumban van.
Rejtett veszély
A párhuzamosság fokozódásának azonban nemcsak előre látható kemény akadályai vannak, mint a támogatott processzorok száma, hanem úgynevezett puha korlátai is, melyekre többnyire a gyakorlatban derül fény. Ilyen például, mikor a processzorszám növelése egy idő után minimális vagy szinte semmilyen teljesítménynövekedést nem hoz magával. Ennek természetesen lehetnek hardverarchitekturális okai is, ami tipikusan a foglalatok közötti összeköttetések vagy a memóriaalrendszer eldugulását takarja, a legtöbb jelenlegi, valamint hamarosan megjelenő rendszernél azonban közel sem erről lesz szó. A Gartner úgy látja, sok szoftvernél a bőven a processzorlimit alatt van a valódi, puha skálázódási határ.
Az extrém hardveres párhuzamosság legjobb példái a Sun Microsystems UltraSPARC T-alapú rendszerei. Egy ilyen chip 8 maggal 64 utasításszálat kezel, legnagyobb kiépítésében pedig 4-utas SMP-rendszert képes alkotni, ami 256 szálat jelent. A fejlesztés alatt álló Niagara III már 16 maggal bír, vagyis 512 szál jelenik meg a rendszerben. Az eddig jól skálázottnak gondolt nagygépes rendszerekben pedig a korábbi néhány tucat szál helyett a következő évek során megjelenő új, sokmagos Power, Itanium vagy UltraSPARC architektúrákkal több száz, a legnagyobb konfigurációknál pedig akár több mint ezer logikai processzor jelenhet meg a szoftverek előtt.
A korábban skálázhatónak hitt szoftverek viselkedése könnyen meglepheti az IT-csapatokat, ami kínos pillanatokat, kapkodást és erőltetett migrációkat eredményezhet, véli a Gartner. Éppen ezért azt tanácsolja, jó előre konzultáljanak a szoftverszállítókkal, és ha lehetőségük nyílik rá, akár teszteljék is a szoftverek viselkedését a jelenleginél jóval magasabb processzorszám mellett is -- már viszonylag alacsony párhuzamosság esetén is hatalmas különbségek bontakozhatnak ki már az akár egyes operációs rendszerek és szoftverek különböző verziói között is. Az illusztráción például mérésben a két legjobban skálázódó és leggyorsabb operációs rendszer (FreeBSD 7.0 és Linux 2.6.22) között is 15 százalék teljesítménybeli különbség látszik MySQL alatt, mindössze 8 magnál (forrás: Kris Kennaway, FreeBSD Project).