OS13V07.RTF,ZSP,2001-04-22
13. RENDSZERHATÁSFOK-VEZÉRLÉS
A 8. fejezetben általánosságban tárgyaltuk az erőforrás-kezelést. Ott elemeztük, hogy az erőforrás-kezelés statikus vagy dinamikus stratégiát követhet. A továbbiakban egyes konkrét erőforrások (CPU, tár, perifériák, adatállományok) lefoglalásának ütemezési algoritmusait vizsgáltuk. Ezek az allokátorok és ütemezők azonban csak lokális optimumokat tudnak megkeresni, mert csak egy adott típusú erőforrás elosztását tudják elvégezni. E szűk látókörű működés miatt egymás munkájáról nem tudnak, döntéseik egymásnak ellentmondanak, de legalábbis megkérdőjelezhetők. (Például: a diszpécser már éppen be tudna ütemezni egy programot, de a tárkezelő elveszi tőle a folytatásához éppen szükséges egyik lapkeretet, és ezzel újra blokkolja.) A nagyteljesítményű számítógépek operációs rendszereiben ezért szükség van olyan szoftver algoritmusokra, amelyek globálisan át tudják tekinteni az erőforráshelyzetet és a rendszerben futó munkák haladását. Ezek a rendszerhatásfokvezérlők. A problémát az IBM 370 OS/MVS rendszer erőforrás--kezelőjének (angolul: SRM = Systems Resource Management) példáján mutatjuk be, így ez az egész fejezet egy komplett mintapélda.
13.1. Az IBM SRM alapelvei Az IBM OS/MVS SRM nem más, mint a korábbi fejezetekben már emlegetett közbenső szintű ütemező. Amint a 13.1. ábra mutatja, az IBM OS/MVS-ben három ütemező van: * Vezérlőáram-olvasó és főütemező, amelyet itt JOB-beléptető alrendszernek (angolul: JES = Job Entry Subsystem) neveznek, amelyről korábban már említettük, hogy nem igazi alrendszer (5.7); * Közbenső szintű ütemező, amelyet itt SRM-nek hívnak; * Diszpécser a CPU-idő(k) ütemezésére. A JES gondoskodik arról, hogy a munkákat beolvassa, majd a végrehajtásra várakozó sorból egyenként átadja a multiprogramozott környezetnek. A képződő újabb vezérlőtáblázatokat azonban nemcsak a diszpécser kezeli (mint a közbenső szintű ütemező nélküli operációs rendszerekben), hanem a diszpécser és az SRM közösen. A közösen kezelt táblázatnak ezért külön neve van: a megkezdett munkák sora. Az MVS-ben a diszpécser további táblázatokat használ a ténylegesen futó munkák nyilvántartására (l. 13.1. ábra). A várakozó munkák sorából akkor kerülhet át egy munka a diszpécser soraiba, ha az SRM ezt engedélyezi. Ennél fontosabb, hogy az SRM a diszpécser soraiból a már átadott munkákat is visszahívhatja átmenetileg, sőt ennél finomabb beavatkozásokkal is befolyásolni tudja a már futó munkák ütemezési esélyeit, ha a rendszerterhelés szélsőséges, vagy ha valamelyik sürgős munka nem a kívánt ütemben halad.
218 OPERÁCIÓS RENDSZEREK ------------------------------------------------------------------O===============o | Végrehajtásra | | várakozó sor | o===============o
+---------------+ | JES | | JOB beléptető | | alrendszer | +---------------+
Magas szintű ütemező Beléptetés a multiprogramozott környezetbe.
------------------------------------------------------------------Közbenső szintű ütemező O===============o | Megkezdett | | munkák sora | o===============o
+---------------+ | | | SRM | | | +---------------+
Figyeli az elindított munkák haladását. Módosítja a rendszer terhelés-eloszlását a kitűzött rendszercélok teljesítése érdekében.
------------------------------------------------------------------o===============o | Aktivizálható | | folyamatok | o===============o o===============o | Futó | | folyamat(ok) | o===============o
Alacsony szintű ütemező
+---------------+ | | | Diszpécser | | | | | +---------------+
Eldönti, hogy az aktivizálható folyamatok sorából melyik kapja meg a CPU-vezérlési jogot.
O===============o | Blokkolt | | folyamatok | o===============o o===============o | Felfüggesztett| | folyamatok | o===============o 13.1. ábra. Az IBM 370 OS/MVS ütemezői Az SRM fő feladata tehát a rendszerterhelés szabályozása. Alacsony és magas rendszerterhelés esetében alkalmasan választja meg az ütemezési politikát. Nagy terhelésnél például segít "átvészelni" a helyzetet. A felhasználó számára ennél fontosabb, hogy az SRM képes a munkák előrehaladásának figyelésére, és el tudja hárítani az esetleges "igazságtalanságokat". Képes a lassan haladó munkák meggyorsítására, és a túl erőszakosak megfékezésére. Az eddigi fejtegetésekből persze még nem lehet világos, hogy lehet megoldani ezt a nagyon heurisztikus döntéseket igénylő feladatot egy számítógépes szoftverrel. Egyáltalán: hogy lehet megtanítani egy programot heurisztikus döntésekre? Természetesen meg kell figyelni, hogy az ember milyen módszerrel alapozza meg döntéseit. Az ember a döntéseit úgy alapozza meg, hogy elegendően sok információt gyűjt össze a vizsgált problémáról. Számítógéppel ugyanezt a szisztémát követhetjük. Adatokat kell gyűjteni a munkák erőforrás-
13. RENDSZERHATÁSFOK--VEZÉRLÉS 219 ------------------------------------------------------------------felhasználásáról. Valóban, az SRM munkáját egy adatgyűjtő fokozat támogatja, amely méri a folyamatok erőforrás-használatát természetes egységekben (másodperc, lapkeretszám, B/K átvitelek száma/hossza stb.). Ez azonban további gondokat okoz. Hogy lehet összevetni a különböző egységekben mért adatokat. Tulajdonképpen sehogy, mint ahogyan két körtét sem lehet öt almával összehasonlítani.
13.2. A szolgáltatás egysége Az SRM leglényegesebb ötlete éppen az, ahogyan a folyamatok előrehaladását mérni tudja. Abból indul ki, hogy a folyamatok a működésükhöz szükséges erőforrásokat komplex módon fogyasztják. Így az előrehaladás méréséhez nem tisztán az egyes erőforrásokból fogyasztott naturáladatokból kell kiindulni, hanem komplex alapegységet kell használni az előrehaladás megítélésére. A folyamatokat emellett célszerű kisebb kiszolgálási egységekre, ún. tranzakciókra szabdalni, és az egyes tranzakciók erőforrás--fogyasztását kell vizsgálni. A szolgáltatás egységét a naturálegységek komplex struktúrájaként lehet megfogalmazni. A szolgáltatás egységének effajta kijelölése során felmerül, hogy az egyes naturál erőforrásokat milyen súllyal vegyük figyelembe. Ennek megállapítását a gyakorlati tapasztalatra lehet csak bízni. Ez tehát egy heurisztikus (szigorú logikával meg nem alapozható) mozzanat, amelyet az SRM üzembeállításakor a rendszerprogramozónak kell megadnia. (Az SRM tehát itt támaszkodik emberi segítségre a heurisztikusnak tűnő döntések megalapozásában.) Az SRM filozófiája szerint a szolgáltatás egységének négy komponense van: * CPU kiszolgálási sebesség (a választott mérési időegység alatt rendelkezésre bocsátott CPU-idő); * B/K kiszolgálási sebesség (az időegység alatt teljesített B/K átvitelek száma); * Tárkiszolgálási tényező (az időegység alatt adott lapkeretek száma); * Rendszerhívás-kiszolgálási sebesség (az időegység alatt a rendszerhívásoknak megadott CPU-idő). Egy tranzakció kiszolgálási sebességét a választott időegység alatt felhasznált (megkapott) szolgáltatási egységekben mérjük. Az OS/MVS rendszerstatisztikai funkciói ezt mérik a folyamatokról vezetett statisztikai adatok alapján. Ez azt jelenti, hogy a folyamatok vezérlőtáblázatait az SRM működtetésének biztosítására újabb adatelemekkel kell bővíteni. Ezek az adatelemek azonban többcélúak, s nemcsak az SRM igényei miatt merülnek fel. Így például ezek alapján történik a számlázás, és ezekre alapozhatók az eseti hardverkarbantartási igények. Végeredményben azt is mondhatjuk, hogy az SRM--szolgáltatásokat melléktermékként kapjuk. A mérési adatok meghatározásánál fontos tényező az időegység megválasztása. Korábban már beszéltünk arról, hogy a különböző szintű ütemezők különböző gyakorisággal lépnek működésbe. Leggyakrabban a diszpécser, legritkábban a magas szintű ütemező (főütemező) aktivizálódik. Várható, hogy a közbenső helyet elfoglaló közbenső szintű ütemezők (így az SRM) működési gyakorisága valahol a kettő között foglal helyet. Jogos kérdés, hogy miért. Mint említettük, az SRM a globális erőforrás-kezelési helyzetet szeretné áttekinteni, ezért nem léphet működésbe túl gyakran, mert ilyen rövid idő alatt nem láthatók a tendenciák. Túl hosszú SRM--ütemezési periódus alatt viszont túlzottan kiátlagolódnának az értékek, és az SRM "lekésne" a közbeavatkozási lehetőségekről. Ez még nem magyarázza meg, hogy az ütemezési periódus miért rövidebb, mint a főütemező periódusa. A főütemező azonban bizonyos mértékig játszhatja ugyanazt a szerepet, mint az SRM. Szabályozási lehetősége abban áll, hogy beengedi-e azonnal a beolvasott JOB-ot a multikörnyezetbe vagy sem. Visszahívni azonban nem tudja a már elindított munkát, szemben az SRM-el, amely azután is be tud
220 OPERÁCIÓS RENDSZEREK ------------------------------------------------------------------avatkozni. Végeredményben ez a magyarázata annak, hogy az SRM ütemezési periódusát a főütemező ütemezési idejének töredékére, de a diszpécser átlagos ütemezési idejénél egy-két nagyságrenddel nagyobbra kell választani. A konkrét érték kiválasztása ugyanúgy heurisztikus mozzanat, mint a szolgáltatás egységének a definiálása. Nem meglepő, hogy a szolgáltatás egységét és az SRM ütemezési időt rendszeresen felül kell bírálnia a rendszerprogramozónak. Ennek több oka van. Egyrészt üzembeállításkor minden számítógépes rendszer az alulterheltség problémáival küszködik, míg az idő haladtával egyre inkább túlterhelési tünetek jelentkeznek. Ezek aztán elmúlnak, amikor a gépet elkezdik kiváltani újabb, párhuzamosan üzemeltetett hardverrel. Ezenkívül vannak szezonális hatások is. A nyári szabadságok (oktatási intézményekben a tanítási szünetek) idején jelentősen lecsökkenhet vagy jellegében erősen átalakulhat a rendszerterhelés. Ezekre a rendszerprogramozónak reagálnia kell, különben az SRM-ben a korábbi terhelésre beállított heurisztika elkezd anomális viselkedési módokat generálni. A mérési adatok gyűjtése nem az SRM feladata, de kiértékelése az SRM ütemezési periodicitásával történik. A mért naturális adatokat az SRM átszámítja szolgáltatási-egység mértékegységekre, és így tudja meghatározni a multiprogramozott környezetben folyamatonként elfogyasztott erőforrásokat. Ez jelenti a folyamatok előrehaladási sebességét, ami alapján az SRM dönteni tud a következő ütemezési periódus tartamára.
13.3. Terhelési szintek Ha a számítógépes rendszerben éppen futó folyamatok szolgáltatási egységekben mért fogyasztásait összeadjuk, és ezt viszonyítjuk a számítógépes rendszer maximális kapacitásához, akkor olyan arányt kapunk, amely a számítógépes rendszer pillanatnyi terhelési állapotát jellemzi. Arányértékek megadásával terhelési szinteket határozhatunk meg. A legegyszerűbb esetben például három szintet tűzhetünk ki: (1) alacsony(mondjuk 0.2 alatt), (2) közepes- (0.5-ig) és (3) magas (0.75 felett) terhelés. A terhelési szinteket az SRM üzembeállításakor lehet beállítani, s ez is heurisztikus módon történik.
13.4. Terhelési sablonok és végrehajtási csoportok A munkákat csoportosíthatjuk várható erőforrásigény--tulajdonságaik (profil) alapján. Így például lehetnek rövid, sürgős, CPU-igényes, B/K-igényes munkák stb. Ezek a működésoptimalizálás eszközeivel eltérően kezelhetők. A kevésbé sürgős vagy a hosszú, B/K igényes munkákat például nem nagyon sújtja, ha időnként egy kicsit visszafogjuk haladásukat. E szituációk megfogására az SRM végrehajtási csoportok és terhelési sablonok definiálásával ad lehetőséget. Egy terhelési sablonban azt lehet megadni, hogy az előző pontban említett terhelési szinteken mennyi kiszolgálási egységet kaphatnak azok a folyamatok, amelyek az adott terhelési sablon szerint kezelendők. Ha van egy koncepciónk arra, hogy milyen csoportokat alkotunk a munkákból, akkor ezekhez a csoportokhoz hozzá kell rendelni egy-egy terhelési sablont. Ezt mutatja a 13.2. ábra. Az ábrából kitűnik, hogy a terhelési sablonok azt adják meg terhelési szintenként, hogy az adott munkacsoport folyamatainak -- SRM ütemezési időegységenként -- mennyi szolgáltatási egységet kell kapniuk. A sürgős munkák előrehaladását például feltétlen minden terhelési szituációban segíteni kell, ezért rájuk általában csak olyan terhelési sablon alkalmazható, amely minden terhelési szinten azonos (és elég nagy) szolgáltatási egységet biztosít a csoport folyamatainak. A lassú munkák a magasabb terhelési szinteken egyre kevesebb
13. RENDSZERHATÁSFOK--VEZÉRLÉS 221 ------------------------------------------------------------------szolgáltatási egységet kaphatnak, ami akár nulla is lehet. A terhelési sablon az SRM-nek csak egy javaslat az egyes ütemezési periódusokban hozandó döntésekhez. A folyamatok ténylegesen haladhatnak az előírtnál lassabban és gyorsabban is. A gyorsabb haladás azonban nem feltétlen probléma, ha például közben hirtelen leesik a rendszerterhelés. Az SRM-nek tehát teljes dinamikájában kell figyelnie a hardver/szoftver rendszert, és úgy kell döntést hoznia a folyamatok továbbhaladásáról. Az érdekesség az, hogy ezt a dinamikus döntési mechanizmust ezekre a meglehetősen statikusnak tűnő terhelésisablon táblázatokra lehet alapozni. 1. Végrehajtási csoport +-----------+ | A program | | B program | | C program | | D program | +-----------+ Sürgős munkák 2. Végrehajtási csoport +-----------+ | E program | | F program | | G program | +-----------+ B/K igényes Munkák
n. Végrehajtási csoport +-----------+ | X program | | Y program | | Z program | +-----------+ Lassú munkák
13.2. ábra.
1. Terhelési sablon
+-------------+ | | +---------+--------------+ | SRM | |Terhelési|Szolgáltatási | | | | szint | egység | +------+------+ +---------+--------------+ | | 1 | 500 | v | 2* | 500* |<-+ o=============o | 3 | 500 | | |Aktuális ter-| +---------+--------------+ +--Xhelési szint | | | = 2 | 2. Terhelési sablon | o=============o | +---------+--------------+ | |Terhelési|Szolgáltatási | | Az SRM először | szint | egység | | kiszámítja a +---------+--------------+ | terhelési szin| 1 | 400 | | tet, majd meg| 2* | 200* |<-+ vizsgálja, hogy | 3 | 100 | | az utolsó idő+---------+--------------+ | szakban megfele. lően haladtak-e . az egyes csopor. tok munkái.Ennek n. Terhelési sablon | megfelelően vál| toztatja meg a +---------+--------------+ | munkák erőforrás |Terhelési|Szolgáltatási | | --foglalási lehe| szint | egység | | tőségeit a kö+---------+--------------+ | vetkező inter| 1 | 200 | | vallum idejére. | 2* | 100* |<-+ | 3 | 0 | +---------+--------------+ Terhelési szintek, terhelési sablonok és végrehajtási csoportok az SRM-ben
222 OPERÁCIÓS RENDSZEREK -------------------------------------------------------------------
13.5. Végrehajtási periódusok A munkák nem minden fázisa viselkedik egyformán az erőforrásigény szempontjából. Ezért a munkák és terhelési sablonok összerendelése nem korlátozható csak a végrehajtási csoportokra. Adott esetben végrehajtási periódusokat is ki lehet jelölni. Ezekhez szintén hozzá kell rendelni egy-egy terhelési sablont. A végrehajtási periódus az az időszak, amelyen belül a folyamat ugyanolyan terhelési sablon szerint kezelendő. Az SRM a munkát áthelyezheti más végrehajtási periódusba, ha megítélése szerint nagyon eltérően halad az előírt terhelési sablontól. Ezzel próbálja korrigálni azt a hibát, amit a folyamat kezdeti besorolásakor követtünk el. Tipikus alkalmazása e lehetőségnek, hogy a rövid terminálparancsokat egy nagyon gyors kiszolgálást biztosító terhelési sablonú végrehajtási periódusba soroljuk. Ha azonban a parancs végrehajtása környezeti okokból lelassul (például azért, mert egy kezdő felhasználó ül a terminálnál, aki folyton téveszt), akkor az SRM a felhasználóval kapcsolatot tartó folyamatot átsorolja egy másik végrehajtási csoportba, amely például csak a lassú folyamatokra érvényes terhelési sablon szerinti kiszolgálást engedi meg.
13.6. Intervallumokra bontott kiszolgálás Az SRM további érdekes működésoptimalizálási finomításokat tartalmaz. Egyik ilyen lehetősége lényegében az időszeletelt CPU-ütemezés analógiája. Itt azonban a folyamatok szolgáltatáskérésekből kapnak szeleteket. Intervallumonként kérhetnek valamennyi kiszolgálási egységet (angolul: ISV = Interval Service Value). A megadott ISV értéket kérő folyamat addig nem szorítható ki a tárból (swappinggal), amíg meg nem kapja a kért szolgáltatási egységnyi kiszolgálást. A kifejezésben található intervallum szó tehát nem egy határozott időtartamra utal, hanem a kért szolgáltatás teljesítéséhez szükséges időtartamot jelenti. Az ISV típusú SRM--vezérlési lehetőség szerepe érezhetően az, hogy csökkenti azt a rendszeradminisztrációs többletidőt (overhead), ami a normál ütemezési algoritmus meghagyása esetén túl sűrű swapping miatt lépne fel. Az SRM-nek ez a szolgáltatása még egy "óvatossági" rendszabályt is alkalmaz. Előfordulhat ugyanis, hogy egy folyamat bejelent egy ISV-t, de saját hibája miatt nem halad elég gyorsan. Az SRM ilyenkor a tárban tartja ugyan a kérelmező kódját (kivéve, ha a helyzet végképp tarthatatlanná válik), de átsorolja a folyamatot valamilyen lassabban kiszolgált csoportba. (Újabb ízelítő abból, milyen trükkös optimalizálási lehetőségekre képes az SRM.)
13.7. Tartományok Még egy optimalizálási eszközt említünk meg az SRM lehetőségei közül. Ezek a tartományok, amelyek -- a munkacsoportok mintájára -- felhasználói csoportok megkülönböztetésére szolgálnak. Elmondható ugyanis, hogy a felhasználók szokásait összefüggésbe lehet hozni az általuk üzemeltetett munkák tulajdonságaival. Egy tartomány az SRM-mel önállóan ütemezhető, adott felhasználói csoporthoz tartozó munkatípus halmaz. Minden tartományra elő lehet például írni egy minimális és maximális multiprogramozhatósági szintet. Az SRM a multiprogramozás fokát az adott tartományból a tárban lévő munkák számával veszi egyenlőnek. Ezt az értéket igyekszik az előírt korlátok között tartani. A tartományok emellett eltérő súllyal vehetnek részt az erőforrásokért vívott versengésben. Az ezt szabályozó tényezőt versengési indexnek nevezzük, és értékét minden tartományra a rendszer üzembeállításakor kell megadni.
13. RENDSZERHATÁSFOK--VEZÉRLÉS 223 ------------------------------------------------------------------Amikor az SRM arról dönt, hogy melyik tartományból hozzon be az aktív sorba egy folyamatot, akkor előnyben fogja részesíteni a nagyobb versengési indexű, illetve a minimálishoz közelebb eső multifaktorú tartományok folyamatait. Megfordítva, amikor ki kell szorítani egy folyamatot a túl nagy rendszerterhelés miatt, akkor az SRM az áldozatot a legalacsonyabb versengési indexű vagy a maximális multifaktorhoz közelebb eső multifaktorú tartományokból választja. Ennyi legyen elég az SRM emberi heurisztikát utánzó képességeinek bemutatásából, de megemlítjük, hogy az algoritmus tökéletesítésén talán még mindig dolgoznak.
13.8. Rendszercélok és taktikák, rendszerhangolás Az SRM lehetővé teszi, hogy a rendszergeneráláskor megtervezett végrehajtási csoportokkal, terhelési szintekkel, terhelési sablonokkal, végrehajtási periódusokkal, ISV-kel és tartományokkal igen tág határok között változtathassuk a számítógépes rendszerünkben elérendő célokat. Például, dönthetünk úgy, hogy úgyis nagyon erős CPU-nk van, ezért a CPU-időt kihagyhatjuk az optimalizálásból. Nagy teljesítményű, drága, "pénzkereső" hardver-arzenál esetében viszont jól felfogott érdekünk minden erőforrás optimális kihasználása. Az SRM--szoftver birtokában a stratégiai és taktikai célok kitűzése az említett táblázatok megadásával lehetséges. Lényeges momentum, hogy az alkalmazónak nem kell emiatt kifejezett programozásba bonyolódnia. Igen bonyolult politikák definiálása is megúszható egy alkalmas paramétersereg megadásával. Az persze nem várható el, hogy a paraméterek beállítását egyből eltaláljuk. Már említettük azt is, hogy a számítógépes rendszerek többé-kevésbé jellegzetes időbeli terhelési diagramot futnak be. Belátható, hogy a kialakított politikát időről időre felül kell bírálni, és ennek megfelelően az SRM paramétertábláit át kell definiálni. Ezt a munkát nevezzük rendszerhangolásnak. Itt jegyezzük meg, hogy más hardvereken és más operációs rendszerekben is alkalmaznak működésoptimalizálási eszközöket, amelyek heurisztikus jellegű döntési algoritmusokat szimulálnak. Ilyen eszköz van például a UNIX-ban, a VAX/VMS-ben és az OS/2-ben, amelyek egyes verzióiban feladattípusonként alkalmasan választandó prioritásintervallumokat lehet meghatározni, és a prioritások automatikus, ideiglenes megnövelése segíti a lassan haladó folyamatok előrejutását, de ennél "trükkösebb" algoritmusokat is használnak.
224 OPERÁCIÓS RENDSZEREK -------------------------------------------------------------------
13.9. Gyakorlatok 13.9.1.
Mi a rendszerhatásfok-vezérlők szerepe?
13.9.2.
Mi az IBM OS/MVS SRM?
13.9.3.
Mit nevezünk heurisztikus algoritmusnak?
13.9.4.
Mi alapján dönt az SRM?
13.9.5.
Mi a szolgáltatás egysége és hogyan definiáljuk?
13.9.6.
Mi a terhelési szint, a végrehajtási csoport, a terhelési sablon és a végrehajtási periódus szerepe az SRM optimalizálási tevékenységében?
13.9.7.
Mi az intervallumokra bontott kiszolgálás szerepe?
13.9.8.
Mit nevezünk tartományoknak az SRM szempontjából, és mit lehet velük elérni?
13.9.9.
Hogyan lehet kialakítani az SRM-mel egy rendszerstratégiát és taktikát?
13.9.10.
Mi a szerepe a rendszerhangolásnak, és hogyan végezhető el?
