A fejezetben bemutott eszközök az alábbi területek feltérképezésében segítenek:

IBM04.qxd

3/22/2006

1:09 PM

Page 53

II rész Teljesítményelemzõ eszközök

IBM04.qxd

3/22/2006

1:09 PM

Page 54

IBM04.qxd

3/22/2006

1:09 PM

Page 55

4 Rendszerteljesítmény-mérés Gerrit Huizenga, Peter Wai Yee Wong, Vaijayanthimala Anand

Bevezetés Ebben a fejezetben olyan eszközökkel foglalkozunk, amelyek révén képet kaphatunk rendszerünk teljesítményérõl. Miután a teljes rendszer teljesítményének jellemzõit megismertük, nekiláthatunk a szûk keresztmetszetek azonosításának. Sok esetben a rendszerfigyelõ eszközök önmagukban is képesek növelni a rendszer teljesítményét, hiszen a segítségükkel felismert problémák megszüntetésébõl azonnal profitálhatunk. Más esetekben ezek az eszközök egyszerûen rámutatnak a problémás alkalmazásokra és folyamatokra. A teljesítményt ilyenkor a beállítások megfelelõ módosításával érhetjük el, szélsõséges esetben azonban akár algoritmikus változásokra is szükség lehet. A fejezetben bemutott eszközök az alábbi területek feltérképezésében segítenek: • • • •

Processzorkihasználtság Memóriakihasználtság Lemez I/O kihasználtság és késleltetés Hálózatkihasználtság

A legtöbb eszköz többféle rendszerjellemzõ megfigyelésére is alkalmas, a fejezet felépítésének egyszerûsítése érdekében azonban az ilyen programokat a legjellemzõbb szolgáltatásaik alapján soroljuk be. Sok esetben kizárólag ezekre az eszközökre támaszkodhatunk, ha meg szeretnénk találni rendszerünk hibáit és megnövelni annak teljesítményét. Elõfordul azonban, hogy ezek a magas szintû eszközök olyan alkalmazásokban vagy feladatcsoportokban fedezik fel a szûk keresztmetszetet, amelyek teljesítményén a rendszer hangolása mit sem változtat. Az ilyen esetekben olyan szoftverre van szükségünk, amellyel jobban megérthetjük az alkalmazás mûködését és az operációs rendszerhez fûzõdõ kapcsolatát; ebben a fejezetben ilyen eszközökkel is megismerkedünk majd.

IBM04.qxd

56

3/22/2006

1:09 PM

Page 56

Linux kiszolgálók teljesítményének fokozása

A Linux és a teljesítményelemzés A Linux elsõsorban annak köszönheti a piacon való megjelenését, hogy voltak, akik felismerték a kis kiszolgálókon elérhetõ nagyszerû ár/teljesítmény arányt. A Linux nagyon hatékonynak bizonyult ezen a területen, és egyre népszerûbb operációs rendszerré vált a szélesebb vállalati piacon. Ez a népszerûség arra buzdította a hardvergyártókat, hogy több processzorral, több processzortípussal, több memóriával és szélesebb I/O lehetõségekkel rendelkezõ rendszerekre is átültessék a Linuxot. A szoftvergyártók hamar felismerték annak elõnyeit, hogy alkalmazásaikat az új operációs rendszeren is elérhetõvé tegyék, a felhasználók pedig egyre összetettebb rendszereket kezdtek használni. A gépek terhelésének növekedése közben a felhasználók korábbi rendszereikkel azonos vagy annál magasabb teljesítményt vártak el. Ezek a megnövekedett várakozások elõször a teljesítmény elemzéséhez, majd az operációs rendszer ütemezõjének, memóriakezelésének, lemezkezelõ és hálózati alrendszereinek továbbfejlesztéséhez vezettek. A szoftvergyártók eleinte belsõleg tesztelték a legfontosabb alrendszereiket, viszonylag kevés, az üzlet szempontjából lényeges alkalmazással. Ezek a gyártók gyakran igen fejlett elemzõeszközökkel, például kifinomult buszmonitorokkal, lapkaszámlálókkal, szimulációs eszközökkel, natív teljesítményfigyelõkkel, és más olyan programokkal dolgoztak, amelyek képesek voltak összetett szoftver- és hardverrendszerek teljesítményének mérésére. Ezeket az összetett eszközöket sok esetben néhány kiválasztott vásárló is megkapta, az így kapott mérési eredményeket pedig a gyártó a beállítások finomhangolására használhatta. A könyvnek ebben a részében ilyen eszközökkel ismerkedünk meg, és összegyûjtjük azokat a fogásokat, amelyekkel a Linux operációs rendszer és a rajta futó alkalmazások teljesítményét javíthatjuk. A Linux új kihívások elé állítja a teljesítményelemzõket, ugyanakkor jó néhány elõnyös tulajdonsággal is bír. A Linux például jóval többféle hardveren képes futni, mint a legtöbb operációs rendszer. Érdemes megemlíteni itt a RISC és CISC gépeket, a 32 és 64 bites rendszereket, az egyprocesszoros gépeket, a beágyazott rendszereket, és kis (2–4 processzoros), illetve a nagy (8–128 processzoros) szimmetrikus többprocesszoros rendszereket. Ezekbõl a Linux rendszerekbõl és az alattuk üzemelõ processzor-összeállításokból sokkal többféle van tehát, mint amennyit bármelyik másik operációs rendszer is megpróbál megcélozni. Gondoljunk csak arra, hogy az adott Linux lehet egy asztali gép, noteszgép, beágyazott rendszer, levelezõkiszolgáló, fájlkiszolgáló, alkalmazáskiszolgáló, adatbázis-kiszolgáló és tartalomszolgáltató is. Ugyanakkor mindezeket a feladatokat ugyanannak a Linux rendszermagnak és ugyanazoknak az alapkönyvtáraknak kell ellátniuk. Mivel a Linux kialakítása olyan, hogy igen különbözõ terhelések mellett is igyekszik jól teljesíteni, jó esélyünk van arra, hogy egy adott feladat végrehajtása esetén csak a rendszer elemzése, a teljesítmény mérése és szükség esetén a rendszer, illetve az alkalmazások hangolása révén hozhatjuk ki a maximumot gépünkbõl.

IBM04.qxd

3/22/2006

1:09 PM

Page 57

4. fejezet • Rendszerteljesítmény-mérés A teljesítményt az ilyen összetett feladatok esetében számos tényezõ befolyásolja. Nyilvánvaló, hogy a processzor sebessége, a memória mérete, a hálózati és lemezvezérlõk száma, a lemezek mérete és sebessége jelentõs mértékben befolyásolják a rendszer teljesítményét. Ezen túlmenõen fontos szerepet játszanak az alkalmazás saját teljesítménymutatói, a terhelés természete, az alkalmazások közötti kapcsolattartás, a lemezen vagy a hálózaton tárolt adatok elérésének módja és természetesen az alkalmazás használati modellje is. Amikor egy adott feladat végrehajtására hangoljuk a rendszert, általában feltételezzük, hogy a környezet fizikai jellemzõi, így a processzorok száma, típusa, a lemezek száma stb. nagyrészt változatlanok maradnak. A teljesítményelemzés elsõdleges feladata az, hogy a szûk keresztmetszetek azonosításával és megszüntetésével megnövelhessük a rendszer teljesítményét. Amennyiben a gyenge teljesítmény abból adódik, hogy a terhelés meghaladta a hardver lehetõségeit, fel kell ismernünk, milyen irányú változtatásokra van szükség. A teljesítményelemzéshez a kereskedelmi forgalomban kapható néhány szoftver mellett számos nyílt forrású eszköz közül választhatunk. A fejezetben bemutatott példák nagy része a 2.4-es rendszermaghoz mellékelt eszközökhöz kapcsolódik, de általában elmondható, hogy ezeket a 2.6-os rendszermagra épülõ kiadásokban is megtaláljuk. Bizonyos esetekben a rendszermag által gyûjtött adatokhoz más felületeken juthatunk hozzá. Az eszközök mindemellett nagyjából hasonló vagy éppen ugyanolyan adatokat szolgáltatnak. Ha az általunk használt kiadás nem tartalmazza valamelyik eszközt, vagy azt gondoljuk, hogy a nálunk futó változat nem a legfrissebb, nézzünk szét a telepítõlemezen, vagy szerezzük be az eszköz legfrissebb változatát a készítõktõl. A http://linuxperf.nl.linux.org/general/tools/tools.html címen például megtaláljuk számos jelenleg elérhetõ eszköz listáját.

Processzorkihasználtság A rendszer teljesítményének egyik legfontosabb mércéje, hogy milyen gyorsan reagál a felhasználó kéréseire. Bár a felhasználók beszámolói általában igen szubjektívek, több olyan számszerûsíthetõ mérce létezik, amelyeket az ilyen esetekben alkalmazni lehet. Az ember például az 50 ezredmásodpercen belüli választ úgy érzékeli, mintha késleltetés nélkül érkezne. Az interaktív alkalmazások, fõleg azok, amelyeknél szöveget kell bevinni, lassúnak tûnnek, ha átlépik ezt a küszöböt. Az összetett rendszerek felhasználói gyakran hozzászoknak a több másodperces válaszidõkhöz, sõt esetenként több percig is hajlandók várni. Minden alkalmazásnak megvan a maga válaszideje, amelyhez a felhasználó a rendszer használatával töltött napok, hetek, hónapok vagy évek során már hozzászokott. Ha a program már nem elégíti ki a felhasználó igényeit, az jelzi a terméktámogatásnál, hogy megnõtt a program válaszideje, esetenként annyira, hogy már nem is tudja elvégezni vele a munkáját.

57

IBM04.qxd

58

3/22/2006

1:09 PM

Page 58


Az ilyen telefonhívások mindig jó alkalmat jelentenek a különféle teljesítményelemzõ programok bevetésére. Ezeket az eszközöket azonban sajnos nem lehet mindenféle összehasonlítási alap nélkül hirtelen bevetni. A probléma megoldásában rengeteget segíthet, ha már a krízis bekövetkezte elõtt is figyeljük az alkalmazás teljesítményét, az adatokból pedig statisztikákat készítünk. Ezen kívül szükség van némi általános tapasztalatra ahhoz, hogy felismerjük a teljesítményromlást okozó problémák jeleit. A következõkben bemutatandó eszközök módszeres használata némi általános tudással párosítva elégséges lehet a teljesítmény szûk keresztmetszetének azonosításához, a probléma felismerése után pedig a rendszergazda vagy a teljesítményelemzõ elvégezheti a szükséges hangolást, módosításokat és beállításokat. A rendszer módszeres elemzése során az egyik alapvetõ feladat a processzor kihasználtságának mérése. A Linux és a legtöbb UNIX alapú operációs rendszer tartalmaz egy a rendszer átlagos teljesítményét mérõ parancsot: $ uptime 17:37:30 up 3 days, 17:06, 7 users, load average: 1.13, 1.23, 1.15

Az átlagos terhelés mérõszámai azt mutatják, hány feladatot lehet a rendszerben átlagosan végrehajtani 1, 5, illetve 15 perc alatt. A végrehajtható feladatok azok, amelyek éppen futnak, illetve amelyek futnának, de a processzorra kell várniuk. Ebben az esetben a rendszer egyetlen processzort tartalmazott, amit a /proc/cpu tartalmából deríthetünk ki: $ cat /proc/cpu processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping : 6 cpu MHz : 647.195 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 1291.05

IBM04.qxd

3/22/2006

1:09 PM

Page 59

4. fejezet • Rendszerteljesítmény-mérés Mivel csak egy processzor van a rendszerben, a mérõszámok azt jelzik, hogy a processzornak hangyányival több dolga van, mint amivel elbír. Magas szinten ez azt jelenti, hogy a gép túlterhelt. Jegyezzük meg: ha az uptime parancs kiadásakor megjelenõ átlagos terhelés valamivel 2.00 alatt van egy kétprocesszoros gép esetében, akkor annak a gépnek van még némi szabad kapacitása. Ugyanez igaz egy négyprocesszoros, de 4.00nál alacsonyabb átlagos terheltségû gépre is. Az átlagos terheltség azonban önmagában még nem minden. Ebben az esetben a kérdéses gép egy laptop volt. A gépen többek között egy levelezõprogram, szövegszerkesztõk, böngészõk, néhány egyedi alkalmazás és egy csevegõprogram futott párhuzamosan. A programok válaszideje a felhasználó számára elfogadható volt. Ez azt jelenti, hogy az operációs rendszer ütemezõje nagyon helyesen azokra a programokra összpontosított, amelyeket a felhasználó a legaktívabban használt. A gép nem kiszolgálóként üzemelt, a magas átlagos terheltség tehát más ügyfeleket nem befolyásolt. Annak ellenére tehát, hogy az eszköz szerint a processzor kihasználtsága teljes, arról semmit sem tudunk, mivel van elfoglalva. Ha a válaszidõ a felhasználó számára elfogadható, valószínûleg nincs értelme mélyebben vizsgálni a rendszer mûködését. Ez a fejezet azonban nem lenne túl érdekes, ha itt most megállnánk. Sok esetben az uptime-hoz hasonló egyszerû eszközök kiválóan alkalmasak arra, hogy kiderítsük, valóban a processzor túlterheltsége okozza-e a lassú válaszidõt. Ha errõl van szó, számos további eszköz létezik, amelyekkel az okok körét tovább szûkíthetjük. Annak érdekében, hogy pontosabban megismerjük a processzor mûködését, három olyan eszközt – vmstat, iostat és top – vizsgálunk meg, amelyek különféle képet adnak a CPU kihasználtságáról. Ezek a parancsok a rendszer más-más részeire összpontosítanak, így több oldalról is megvizsgálhatjuk a processzor kihasználtságát. A következõ lépésben például azt kell megállapítanunk, hogy a processzor az operációs rendszerben (más szóval a rendszermag terében), az alkalmazásokban (más szóval a felhasználó terében) vagy üresjáratban tölti-e ideje nagyobb részét. Ha a processzor munka nélkül van, akkor a végére kell járnunk annak, hogy miért tétlenkedik. Ennek számos oka lehet. Az egyik legnyilvánvalóbb ok az, hogy egy folyamat nem tud futni. Ez túlságosan nyilvánvalónak tûnik, de ha nem fut az alkalmazásunkhoz tartozó valamelyik folyamat, az súlyosan befolyásolhatja a teljesítményt. Bizonyos problémás helyzetekben az alkalmazások képesek ugyan tovább futni, de csak csökkentett teljesítménnyel. Az internetes tartománynév-kiszolgálót például sokszor úgy állítják be, hogy lépjen kapcsolatba a named nevû démonnal vagy egy másik gépen futó szolgáltatással. Ha valamelyik szolgáltató – például az, amelyik elsõként szerepel az /etc/resolv.conf fájl name-server sorában – üzemképtelen, elképzelhetõ, hogy a rendszer csak egy bizonyos idõ elteltével fordul másik kiszolgálóhoz. A felhasználó ebbõl mindössze annyit vesz észre, hogy az alkalmazás nagyon lassan válaszol. Ha valaki

59

IBM04.qxd

60

3/22/2006

1:09 PM

Page 60


megnézi az uptime eredményét, láthatja, hogy a processzor nincs túlterhelve. Ebben az esetben a vmstat futásának eredménye segíthet leszûkíteni a lehetséges okok körét. Az ebben és a következõ két fejezetben bemutatott eszközök segítenek kitalálni, mit csinál éppen a számítógép processzora. Ennek a tudásnak a birtokában elméleteket gyárthatunk, amelyeket azután meg kell próbálnunk igazolni.

vmstat A vmstat egy valósidejû teljesítményfigyelõ eszköz. A vmstat parancs segítségével a rendszer olyan szokatlan tevékenységeire világíthatunk rá, amelyek csökkenthetik annak teljesítményét; ilyenek például a gyakori laphibák és környezetváltások. Az adatok frissítésének gyakorisága paraméterezhetõ. A vmstat kimenete valahogy így fest: procs ---------memory--------- ---swap-- ----io---r b swpd free buff cache si so bi bo 18 8 0 5626196 3008 122788 0 0 330403 454 18 15 0 5625132 3008 122828 0 0 328767 322 17 12 0 5622004 3008 122828 0 0 327956 130 22 2 0 5621644 3008 122828 0 0 327892 689 23 5 0 5621616 3008 122868 0 0 323171 407 21 14 0 5621868 3008 122868 0 0 323663 23 22 10 0 5625216 3008 122868 0 0 328828 153

--system-in cs 2575 4090 2544 4264 2406 3998 2445 4077 2339 4037 2418 4160 2934 4518

----cpu---us sy id wa 91 8 1 0 91 8 0 0 92 8 0 0 92 8 0 0 92 8 1 0 91 9 0 0 90 9 1 0

A vmstat az alábbi adatokat gyûjti össze: • A process részben az éppen futó (r), illetve a blokkolt (b) folyamatok számát látjuk. Itt gyorsan ellenõrizhetjük, hogy ezek a számok megfelelnek-e az elvárásainknak. Ha nem, akkor számos dolgot megvizsgálhatunk: az alkalmazás és a rendszermag paramétereit, a rendszer és az I/O ütemezõjét, a folyamatok eloszlását a processzorok között stb. • A memory részben a lemezre kihelyezett (swpd) és a szabad (free) memóriának, az I/O adatszerkezetek átmeneti tárának (buff), illetve a lemezrõl olvasott fájlok gyorsítótárának (cache) méretét olvashatjuk le kilobájtban. A swpd értéke a kswapd tevékenységére utal. • A swap részbõl kiderül, hány kilobájtnyi adatot kell másodpercenként a lemezre kihelyezni (so), illetve onnan visszaolvasni (si). Jegyezzük meg, hogy az so a kswapd tevékenységét tükrözi, miközben az az adatokat a lemezre menti, míg az si értéke azokról a laphibákról árulkodik, amelyek hatására lapokat kell visszaolvasni a lemezrõl. • Az io részben megtudhatjuk, hogy hány blokkot olvasunk a különbözõ eszközökrõl másodpercenként (bi) és mennyit írunk ki rájuk (bo). A nagy I/O terhelést jelentõ alkalmazások esetében ezekre az értékekre különösen oda kell figyelnünk.

IBM04.qxd

3/22/2006

1:09 PM

Page 61

4. fejezet • Rendszerteljesítmény-mérés • A system részben az egy másodpercre esõ megszakítások (in) és környezetváltások (cs) számát olvashatjuk le. • A cpu részbõl kiderül, hogy a processzor az idejének hány százalékát töltötte a felhasználó (us) és hányat a rendszer (sy) feladatainak végzésével, mennyi ideig volt tétlen (id) és mennyit kellett I/O mûveletek befejezésére várnia (wa). Ha a wa értéke magas, vizsgáljuk meg az I/O alrendszert. Így kiderülhet például, hogy az I/O vezérlõk és a lemezek számának növelésével csökkenthetjük az I/O mûveletek várakozási idejét. Intenzív I/O terhelés esetén a bi és a bo értékébõl megtudhatjuk az adatátvitel sebességét, az in értékébõl pedig a megszakítások számát. Az swpd, si és so értékekbõl kiderül, mennyi memóriát kell a rendszernek ideiglenesen a lemezre költöztetnie. Leggyakrabban a processzor kihasználtságát, illetve az us, sy, id és wa értékeket kell megvizsgálnunk. Ha a wa nagy, akkor az I/O alrendszert kell szemügyre vennünk. Elképzelhetõ, hogy arra jutunk, hogy az I/O várakozási idõk csökkentéséhez több I/O vezérlõt, illetve lemezt kell üzembe helyeznünk. Az uptime-hoz hasonlóan a kapcsolók nélkül futtatott vmstat a rendszer aktuális állapotáról ad képet. Ha az uptime és a vmstat parancsokat egymás után adjuk ki, gyorsjelentést kapunk arról, mennyire elfoglalt a rendszer, és némi útmutatást ahhoz, hogy éppen mivel foglalkozik. A vmstat ezen kívül az éppen futtatható folyamatok számáról is tájékoztat. Jegyezzük meg, hogy az uptime három idõtartamra (1 perc, 5 perc és 15 perc) vetítve adja meg a futtatható folyamatok számát. Ha tehát az uptime által közölt átlagos terhelés bármelyik idõtartamban is nagyobb egynél, a vmstat által jelentett futtatható folyamatok számának is egy körül kell lennie. A vmstat képes arra is, hogy szabályos idõközönként friss adatokat közöljön. Az alábbi parancs kiadásával még dinamikusabb képet kaphatunk rendszerünkrõl: $ vmstat 5 10

Ez a parancs tíz alkalommal, 5 másodperces várakozással jeleníti meg a vmstat eredményét. Amennyiben az elmúlt 1/5/15 percben az uptime egy körüli átlagos terhelést jelez, a vmstat is egy körüli futtatható feladatszámot fog adni. Ennek ellenére nem szabad meglepõdni, ha idõnként 5, 7 vagy akár 20 is megjelenik itt. Ne felejtsük el, hogy míg az uptime átlagos értékeket közöl, addig a vmstat a pillanatnyi helyzetrõl tájékoztat. Mindkét nézetnek megvan a maga haszna a teljesítményelemzés során. A vmstat körülbelüli képet ad arról is, mennyi idõt tölt a processzor az operációs rendszerben, mennyit a felhasználói alkalmazásokban, mennyit tétlenkedik, és mennyi idõt tölt el I/O mûveletekre várakozva. A különféle típusú feladatok más-más mintákat követnek, így nincsenek egyértelmû szabályok arra, mikor jó egy érték és mikor rossz. Ezekben az esetek-

61

IBM04.qxd

62

3/22/2006

1:09 PM

Page 62


ben sokat segíthet, ha van összehasonlítási alapunk, azaz meg tudjuk állapítani, milyen változások váltják ki a válaszidõ vagy a terheltség növekedését. A vmstat segít kiválasztani azokat az eszközöket, amelyekkel pontosabban behatárolhatjuk a problémák okait. A hátralévõ részben néhány példát nézünk meg. Képzeljünk el egy olyan esetet, hogy a felhasználók egy adott feladat kapcsán gyenge válaszidõkre kezdenek panaszkodni. Az uptime értékeinek vizsgálata azt mutatja, hogy az átlagos terhelés alacsony, esetleg még a szokásosnál is alacsonyabb. A vmstat futtatása után kiderül az is, hogy a futtatható feladatok száma is alacsony, és a rendszer a processzoridõ jelentõs részét tétlenül tölti. Egy elemzõ ebbõl arra következtethet, hogy valamelyik kulcsfontosságú folyamat leállt, vagy hosszú várakozásra kényszerült. Egyes alkalmazások például valamilyen szemaforos megoldással kiadják a munkát, majd várnak annak befejezõdésére. Ha a munkát egy olyan kiszolgálónak vagy alkalmazásnak adtuk oda, amely valamilyen okból teljesen leállt, a mi alkalmazásunk hiába várakozik a szemaforra, sosem fog tudni továbblépni. A rendszergazda ilyenkor a kiszolgáló alkalmazásra összpontosít, és megpróbálja kideríteni, miért nem kapunk választ a kérésünkre. Nézzünk most egy másik esetet. Az átlagos terhelés meghaladja az 1-et, akár egy teljes ponttal is magasabb a szokásosnál. Ezen kívül a vmstat futtatásakor kiderül, hogy egy vagy két futtatható folyamat mindig van a rendszerben, a felhasználóra fordított processzoridõ pedig hosszabb idõn keresztül 100 százalék közelében van. Ilyenkor szükségünk lesz egy másik eszközre, amellyel kideríthetjük, melyik alkalmazás használja el a teljes processzoridõt. Ilyen eszköz például a top(1) és a ps(1). A ps(1) kiírja az összes létezõ folyamatot vagy a beállításoknak megfelelõen azok egy részhalmazát. A top(1) – vagy gtop(1) – folyamatosan frissülõ képet ad a legaktívabb folyamatokról, ahol a legaktívabb a processzort legnagyobb mértékben használó folyamatot jelenti. Ez az adat segíthet azonosítani azokat az elszabadult folyamatokat, amelyek valójában semmi hasznosat nem csinálnak. Ha a vmstat(1) azt jelenti, hogy a processzor fõleg a felhasználói alkalmazásokkal van elfoglalva, a rendszergazda egy hibakeresõ programmal – például gdb(1) – megpróbálja feltérképezni a problémás alkalmazást. Ha a vmstat szerint maga az operációs rendszer emészti fel a processzoridõt, más eszközök, például az strace(1) segítségével kideríthetjük, milyen rendszerhívások okozzák a problémát. Ha a vmstat (1) szerint a processzoridõt elsõsorban az I/O mûveletek viszik el, a sar(1)-hoz hasonló programokkal megtudhatjuk, mely eszközöket használjuk, és képet kaphatunk arról is, mely alkalmazásokról és milyen fájlrendszerekrõl van szó. A vmstat(1) segítségével képet kaphatunk a rendszer állapotáról. Ebben a részben elsõsorban a processzor kihasználtságával foglalkoztunk. A vmstat(1)-nak azonban a memóriahasználatról és az I/O tevékenységrõl is van mondanivalója. A fejezet késõbbi részében részletesebben is megnézzük ezeket.

IBM04.qxd

3/22/2006

1:09 PM

Page 63

4. fejezet • Rendszerteljesítmény-mérés

top és gtop A top és a gtop segítségével jobban megismerhetjük azokat a feladatokat és folyamatokat, amelyek mûködésérõl a vmstat és az uptime magas szinten már tájékoztatott bennünket. Megtudhatjuk, melyek az aktív folyamatok, és melyek fogyasztják a legtöbb processzoridõt, illetve memóriát. A top parancs folyamatosan frissülõ képet ad a futó folyamatokról és a rendszer terheltségérõl. A top folyamatonkénti bontásban tájékoztat a processzor terheltségérõl és a memóriakihasználtságról. Megtaláljuk itt az uptime-ból már ismert átlagos terheltségi értékeket is. A top ezen kívül aszerint is képes csoportosítani a folyamatokat, hogy melyek futnak éppen, és melyek alszanak. Az alvó folyamatok azok, amelyek valamilyen tevékenységre várnak, például egy billentyû lenyomására, egy másik géptõl érkezõ kérésre (a webkiszolgáló például arra vár, hogy valaki kérjen tõle egy weblapot) stb. A top(1) ezen kívül képes megmutatni az egyes processzorok átlagos terheltségét, így könnyen felismerhetjük az ütemezésbõl fakadó gondokat. A top alapértelmezés szerint gyakran frissíti az eredményét, a feladatokat pedig a processzorhasználat szerint rendezi. Ezen bármikor változtathatunk; átrendezhetjük például a feladatokat az összesített processzorhasználat és a memóriahasználat szerint is. 4:52pm up 5:08, 3 users, load average: 2.77, 5.81, 3.15 37 processes: 36 sleeping, 1 running, 0 zombie, 0 stopped CPU0 states: 5.1% user, 53.1% system, 0.0% nice, 41.1% idle CPU1 states: 5.0% user, 52.4% system, 0.0% nice, 41.4% idle Mem: 511480K av, 43036K used, 468444K free, 0K shrd, Swap: 263992K av, 0K used, 263992K free PID 1026 7490 3 4 1 2 5 6 7 9 10 331 341 356

USER root root root root root root root root root root root root root rpc

PRI NI SIZE RSS SHARE STAT 2 0 488 488 372 S 11 0 1012 1012 816 R 19 19 0 0 0 SWN 19 19 0 0 0 SWN 9 0 536 536 468 S 9 0 0 0 0 SW 9 0 0 0 0 SW 9 0 0 0 0 SW 9 0 0 0 0 SW 9 0 0 0 0 SW 9 0 0 0 0 SW 9 0 844 844 712 S 9 0 1236 1236 464 S 9 0 628 628 536 S

%CPU 1.1 0.5 0.3 0.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0

%MEM 0.0 0.1 0.0 0.0 0.1 0.0 0.0 0.0 0.0 0.0 0.0 0.1 0.2 0.1

TIME 0:00 0:00 0:00 0:00 0:04 0:00 0:00 0:00 0:00 0:00 0:00 0:00 0:00 0:00

2196K 21432K

COMMAND chat_s top ksoftirqd_C ksoftirqd_C init keventd kswapd bdflush kupdated scsi_eh_0 khubd syslogd klogd portmap

63

IBM04.qxd

64

3/22/2006

1:09 PM

Page 64


A top a következõkrõl tájékoztat bennünket: • Az elsõ sorból kiderül, mennyi a pontos idõ, mennyi idõ telt el az utolsó rendszerindítás óta, hány felhasználó van éppen a rendszerben, és megtaláljuk itt az átlagos terheltséget jelzõ három értéket is. Az átlagos terheltség az elõzõ 1, 5 és 15 perc során futásra kész feladatok átlagos számát jelenti. • A második sorban a folyamatok statisztikáit látjuk, többek között a top képernyõjének utolsó frissítése óta futtatott folyamatok számát. Ebben a sorban olvashatjuk le az alvó, a futó, a zombi és a leállított folyamatok számát is. • A 3. és a 4. sor az egyes processzorok adatait gyûjti össze. Kiderül, melyik processzor mennyi idejét használták fel a felhasználók, a rendszer feladatai, a niced, illetve a tétlenség. • Az 5. sor a memória statisztikáit tartalmazza, például a teljes, a felhasznált, a szabad, a különbözõ folyamatok által megosztott és az átmeneti tárak (buffer) számára fenntartott memóriát. • A 6. sor a virtuális memória és a csereterület (swap) statisztikáit adja meg, többek között a rendelkezésre álló, a felhasznált, a szabad és a gyorsítótárba másolt csereterület méretét. • A fennmaradó sorok az egyes folyamatok adatait tartalmazzák. A top indításakor kapcsolókat is használhatunk; a leghasznosabb kapcsolók a következõk: d Az adatok frissítései között eltelõ idõ. p Kizárólag a megadott folyamat adatai jelenjenek meg. Legfeljebb 20 folyamatot adhatunk meg így. S A folyamatok és azok gyermekei által eltöltött idõ összesítése. I A nem futó folyamatok ne jelenjenek meg a listában. H A folyamatokhoz tartozó összes szál megjelenítése. N Hány alkalommal szeretnénk jelentést kapni. A top parancsot futtathatjuk dinamikusan is. A dinamikus üzemmódot az F billentyû lenyomásával érhetjük el. Ha ezután lenyomjuk a J billentyût, a táblázat kiegészül egy új oszloppal, ahonnan kiderül, melyik processzor futtatta utoljára az adott folyamatot. Ez kulcsfontosságú lehet az SMP rendszerekben futó folyamatok viselkedésének megértéséhez. Ebben a részben csak felületesen érintettük a top, illetve a gtop segítségével megjeleníthetõ adatok sorát. Ha többet szeretnénk megtudni ezekrõl, olvassuk át a top parancs man oldalát vagy a gtop beépített súgóját.

sar A sar a sysstat csomag része. A sar számos különféle rendszertevékenységrõl képes adatokat gyûjteni, többek között a processzor kihasználtságáról, a környezetváltások és a megszakítások gyakoriságáról, a lapok lemezre írásának és beolvasásának gyakoriságá-

IBM04.qxd

3/22/2006

1:09 PM

Page 65

4. fejezet • Rendszerteljesítmény-mérés ról, a megosztott memóriahasználatról, az átmenetitár-használatról és a hálózathasználatról. A sar(1) nagyon hasznos, mivel folyamatosan gyûjti az adatokat, az eredményeket pedig naplófájlokban rögzíti, így könnyen összehasonlíthatjuk a rendszer teljesítményromlás utáni, illetve azt megelõzõ állapotát. A sar adatai alapján sokszor meghatározható a teljesítmény visszaesését okozó esemény ideje. A sar a vmstat-hoz hasonlóan alkalmas arra is, hogy rövid idõközönként vagy elõre meghatározott alkalommal jelentsen. A sar ezen kívül az összegyûjtött adatpontok átlagos számát is képes megadni. A következõ példában egy négyprocesszoros SMP rendszer adatait látjuk, amelyrõl 5 másodpercenként kértünk adatokat: Processzorhasználat 11:09:13 11:09:18 11:09:18 11:09:18 11:09:18 11:09:18 11:09:23 11:09:23 11:09:23 11:09:23 11:09:23 . . . Average: Average: Average: Average: Average:

CPU all 0 1 2 3 all 0 1 2 3

%user 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

%nice 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

all 0 1 2 3

0.00 0.00 0.00 0.01 0.00

0.00 0.00 0.00 0.00 0.00

%system %iowait 4.70 52.45 5.80 57.00 4.80 49.40 6.00 62.20 2.40 41.12 3.75 47.30 5.39 37.33 2.80 41.80 5.40 41.60 1.40 68.60 4.22 8.32 2.12 4.16 2.29

16.40 24.33 14.35 12.07 14.85

%idle 42.85 37.20 45.80 31.80 56.49 48.95 57.29 55.40 53.00 30.00 79.38 67.35 83.53 83.76 82.86

A processzoridõ egy része a hálózat és a lemezek kezelésére megy el. Amikor az operációs rendszer I/O mûveleteket kezdeményez, a megfelelõ eszköz alrendszere egy megszakítással jelzi, hogy elkészült. Az operációs rendszer összeszámolja ezeket a megszakításokat; az eredmény alapján pedig pontos képet kaphatunk a hálózat és a lemezek mûködésérõl. A sar(1) ebben is segít. A megszakítások gyakoriságának nyomon követésével a teljesítmény visszaesésének egy újabb okát fedezhetjük fel. A megszakításokról az –I SUM kapcsolóval kérhetünk adatokat, beleértve az egy másodpercre esõ megszakítások számát is. Az –I ALL kapcsolóval az összes megszakításforrásra megkaphatjuk ugyanezt.

65

IBM04.qxd

66

3/22/2006

1:09 PM

Page 66

Linux kiszolgálók teljesítményének fokozása Megszakítások gyakorisága 10:53:53 10:53:58 10:54:03 10:54:08 10:54:13 10:54:18 10:54:23 10:54:28 . . . Average:

INTR sum sum sum sum sum sum sum

intr/s 4477.60 6422.80 6407.20 6111.40 6095.40 6104.81 6149.80

sum

4416.53

Ha egy SMP rendszerben szeretnénk processzoronként látni a megszakítások eloszlását, a sar –A parancsot kell kiadnunk (az alábbiakban a parancs kiadásakor kapott eredménynek csak egy részét látjuk). Vegyük észre, hogy a rendszer a 0, 1, 2, 9, 12, 14, 17, 18, 21, 23, 24 és 25 megszakításértékeket használja. A lapszélesség korlátai miatt a 9, 12, 14 és 17 számú megszakításokat kivágtuk. Megszakítások eloszlása 10:53:53 10:53:58 10:53:58 10:53:58 10:53:58 Average: Average: Average: Average:

CPU i000/s i001/s i002/s … i018/s i021/s i023/s i024/s i025/s 0 1000.20 0.00 0.00 … 0.40 0.00 0.00 3.00 0.00 1 0.00 0.00 0.00 … 0.00 0.00 0.00 0.00 2320.00 2 0.00 0.00 0.00 … 0.00 1156.00 0.00 0.00 0.00 3 0.00 0.00 0.00 … 0.00 0.00 0.00 0.00 0.00 0 999.94 0.00 0.00 … 1.20 590.99 0.00 3.73 0.00 1 0.00 0.00 0.00 … 0.00 0.00 0.00 0.00 926.61 2 0.00 0.00 0.00 … 0.00 466.51 0.00 0.00 1427.48 3 0.00 0.00 0.00 … 0.00 0.00 0.00 0.00 0.00

A megszakítások eloszlásának vizsgálata felfedheti a megszakítások feldolgozásával kapcsolatos problémákat. A következõ lépés ilyenkor az ütemezõ vizsgálata. A probléma egy lehetséges megoldása, ha a megszakításokat egy vagy néhány meghatározott processzorhoz kötjük. Ha például a /proc/irq/ID fájlban, ahol az ID az eszközt jelenti, a 0x0001 értéket helyezzük el, akkor ennek az eszköznek a megszakításait minden esetben a 0-s számú processzor kezeli majd. Hasonlóan, a 0x000f érték a 0–3. processzorokra korlátozza az adott megszakítást. Bizonyos feladatok esetén ezzel a módszerrel csökkenthetjük az erõsen terhelt processzorokért való küzdelmet. A módszer révén ráadásul a megszakítások feldolgozása is hatékonyabbá is válik, ezáltal pedig növekszik a rendszer teljesítménye.

IBM04.qxd

3/22/2006

1:09 PM

Page 67


Memóriakihasználtság A különbözõ feladatok hajlamosak magukhoz ragadni minden elérhetõ memóriát. A Linux hatékony hozzáférést biztosít a fizikai memóriához, és képes hatalmas méretû virtuális memóriát biztosítani a feladatok számára. A virtuális memória általában egy kicsit több annál, mint hogy a rendszer a ritkábban használt adatokat a lemezre írja, miközben a feladatok abban a tudatban futnak, hogy hatalmas memóriamennyiség áll a rendelkezésükre. A memória tartalmának lemezre írása sajnos igen költséges, az ily módon lemezre került adatok eléréséhez esetenként tíz, sõt akár százszor több idõre van szükség. Igen komoly hatással lehet tehát az alkalmazások teljesítményére, ha a rendszer nem a megfelelõ lapokat helyezi ki a lemezre, vagy ha az alkalmazás egyszerûen több memóriával próbál gazdálkodni, mint amennyi fizikailag a rendszer rendelkezésére áll. A teljesítménnyel kapcsolatos problémákat sok esetben a túl kevés memória okozza, ami a lapok lemezre helyezéséhez vezet. Szükségünk van tehát olyan eszközökre, amelyekkel megfigyelhetjük a memóriahasználatot, megtudhatjuk például, mennyi memóriát fogyasztanak az egyes folyamatok, illetve szálak, és mennyi memóriára van szükség a rendszermag adatszerkezeteinek tárolásához. A processzorhasználathoz hasonlóan a rendszer és az egyes folyamatok viselkedésének megértése kulcsfontosságú a túl kevés memória okozta teljesítményproblémák felkutatásában.

/prc/meminfo és /proc/slabinfo A Linux a rendszermemória használatáról a /proc fájlrendszer alatt ad tájékoztatást, név szerint a /proc/meminfo és a /proc/slabinfo fájlokban. Ezek a fájlok a fizikai memória állapotát írják le. A /proc/meminfo tartalma valahogy így fest: MemTotal: MemFree: Buffers: Cached: SwapCached: HighTotal: HighFree: LowTotal: LowFree: SwapTotal: SwapFree: Mapped: Slab:

8282420 7942396 46992 191936 0 7470784 7232384 811636 710012 618492 618492 36008 36652

kB kB kB kB kB kB kB kB kB kB kB kB kB

A MemTotal a rendszerben lévõ fizikai memória teljes méretét, míg a MemFree a használaton kívüli memória nagyságát adja meg.

67

IBM04.qxd

68

3/22/2006

1:09 PM

Page 68


A Buffers az I/O mûveletekhez használt átmeneti tárak méretére, a Cached pedig a fájlok lemezrõl történõ olvasásához használt gyorsítótár méretére vonatkozik. A SwapCached a gyorsítótárnak azt a részét jelenti, amelyet ki kellett helyezni lemezre. A SwapTotal a memória kihelyezésére felhasználható lemezterület teljes mérete. A HighTotal az 860 MB feletti fizikai memória méretét adja meg. A LowTotal a rendszermag által használt memória mérete. A Mapped a memóriára leképezett fájlokra vonatkozik. A Slab a rendszermag adatszerkezeteihez használt memóriát jelenti. A /proc/meminfo eredményét idõrõl idõre lekérve jó képet kaphatunk a memóriahasználatról. Ezt egyszerû parancsfájlok és grafikus eszközök segítségével akár láthatóvá is tehetjük. A rendszermag memóriahasználatáról a /proc/slabinfo fájlban tájékozódhatunk. A /proc/slabinfo kimenetének egy része így fest: tcp_bind_bucket tcp_open_request inet_peer_cache secpath_cache flow_cache

56 16 0 0 0

224 58 0 0 0

32 64 64 32 64

2 1 0 0 0

2 1 0 0 0

1 1 1 1 1

Az elsõ oszlopban a rendszermag adatszerkezeteinek neveit találjuk. Az elsõ sorból például kiderül, hogy összesen 224 tcp_bind_bucket objektum létezik, amelyek közül 56 aktív. Minden adatszerkezet 32 bájtot foglal. Két olyan lap van, amely legalább egy aktív objektumot tartalmaz, és összesen két lapot foglalnak ezek az objektumok, továbbá minden objektumhoz egy lap tartozik. Ezeknek az adatoknak a vizsgálatával könnyen felismerhetjük azokat az adatszerkezeteket, amelyekre jobban oda kell figyelnünk. A meminfo és a slabinfo eredménye alapján tehát felismerhetjük az operációs rendszernek azokat az elemeit, amelyek a legtöbb memóriát fogyasztják. Ha a LowFree és a HighFree értékek viszonylag alacsonyak (vagy alacsonyabbak a szokásosnál), az azt jelentheti, hogy a rendszertõl a szokásosnál több memóriát igényelnek, ez pedig a teljesítmény csökkenéséhez, az alkalmazások válaszidejének növekedéséhez vezethet.

IBM04.qxd

3/22/2006

1:09 PM

Page 69


ps Ha meg szeretnénk tudni, mennyi memóriát használnak a különbözõ folyamatok, vizsgáljuk meg a ps parancs kimenetét: $ ps aux USER PID %CPU %MEM root 1 0.0 0.0 root 2 0.0 0.0 root 3 0.0 0.0 root 4 0.0 0.0 root 5 0.0 0.0 root 48 0.0 0.0 root 63 0.0 0.0 root 64 0.0 0.0

VSZ 1528 0 0 0 0 0 0 0

RSS 528 0 0 0 0 0 0 0

TTY ? ? ? ? ? ? ? ?

STAT S SN S< S< S< S< S S

START 15:24 15:24 15:24 15:24 15:24 15:24 15:24 15:24

TIME 0:00 0:00 0:00 0:00 0:00 0:00 0:00 0:00

COMMAND init [2] [ksoftirqd/0] [events/0] [khelper] [kacpid] [kblockd/0] [pdflush] [pdflush]

A ps aux kimenetébõl kiderül, hány százalékát fogyasztják el az egyes folyamatok a teljes rendszermemóriának, jelenleg mennyi memóriát használnak (RSS), és megkapjuk a virtuális memóriabeli „lábnyomát” (footprint; VSZ) is. A top(1) képes interaktív módon átrendezni a listát, így kiderül, melyik folyamat igényli a legtöbb memóriát, és megfigyelhetjük azt is, hogyan változik a memóriahasználat az idõ során. Miután azonosítottuk a számunkra érdekes folyamatot, a folyamatok virtuális címterének vizsgálatával közelebbrõl is megvizsgálhatjuk annak memóriafoglalásait. A /proc/pid/maps fájlban, ahol a pid a folyamat azonosítója (az azonosítót a ps és a top kimenetében egyaránt megtaláljuk), a folyamathoz kapcsolódó összes memóriafoglalásról képet kapunk. A memóriatartományok mellett megtaláljuk a lapokhoz kapcsolódó jogosultságokat, és az adott memóriatartományhoz tartozó háttértárat is (ha van ilyen). A /proc/pid/maps valójában nem tartozik a teljesítményelemzõ eszközök közé, segítségével azonban képet kaphatunk a memóriahasználatról. Ellenõrizhetjük például, hogy egy adott megosztott memóriaterület mérete 1 GB és 2 GB közé esik-e. Az alábbiakban a 3162 azonosítójú folyamat memóriahasználatát látjuk: $ cat /proc/3162/maps 08048000-08056000 r-xp 00000000 ¯ battstat-applet-2 08056000-08058000 rw-p 0000d000 ¯ battstat-applet-2 08058000-08163000 rw-p 08058000 40000000-40016000 r-xp 00000000 40016000-40017000 rw-p 00015000

03:05 33015

/usr/lib/gnome-applets/

03:05 33015

/usr/lib/gnome-applets/

00:00 0 03:02 40006 03:02 40006

/lib/ld-2.3.2.so /lib/ld-2.3.2.so

69

IBM04.qxd

70

3/22/2006

1:09 PM

Page 70

Linux kiszolgálók teljesítményének fokozása 40017000-40018000 rw-p 40017000 00:00 40018000-4001a000 r-xp 00000000 03:05 ¯ lib/common/xlcDef.so.2 4001a000-4001b000 rw-p 00001000 03:05 ¯ lib/common/xlcDef.so.2 4001b000-4001d000 r-xp 00000000 03:05 4001d000-4001e000 rw-p 00001000 03:05 4001f000-40023000 r-xp 00000000 03:05 ¯ loaders/libpixbufloader-png.so 40023000-40024000 rw-p 00003000 03:05 ¯ loaders/libpixbufloader-png.so 40025000-40031000 r-xp 00000000 03:05 ¯ libpanel-applet-2.so.0.0.19 40031000-40032000 rw-p 0000c000 03:05 ¯ libpanel-applet-2.so.0.0.19 40032000-400d2000 r-xp 00000000 03:05 ¯ libgnomeui-2.so.0.600.1 400d2000-400d6000 rw-p 0009f000 03:05 ¯ libgnomeui-2.so.0.600.1 400d6000-400d7000 rw-p 400d6000 00:00 400d7000-400df000 r-xp 00000000 03:05 400df000-400e0000 rw-p 00007000 03:05 400e0000-400f4000 r-xp 00000000 03:05 400f4000-400f5000 rw-p 00013000 03:05

0 578493

/usr/X11R6/lib/X11/locale/

578493

/usr/X11R6/lib/X11/locale/

128867 128867 514375

/usr/lib/gconv/ISO8859-1.so /usr/lib/gconv/ISO8859-1.so /usr/lib/gtk-2.0/2.4.0/

514375

/usr/lib/gtk-2.0/2.4.0/

337881

/usr/lib/

337881

/usr/lib/

337625

/usr/lib/

337625

/usr/lib/

0 53 53 51 51

/usr/X11R6/lib/libSM.so.6.0 /usr/X11R6/lib/libSM.so.6.0 /usr/X11R6/lib/libICE.so.6.3 /usr/X11R6/lib/libICE.so.6.3

vmstat A vmstat parancsot a processzorhasználat kapcsán ismertük meg. Ennek ellenére elsõdleges célja a memóriahasználat és az I/O tevékenység nyomon követése. A vmstat olyan rendhagyó tevékenységekrõl tájékoztat, mint a túl gyakori laphibák, illetve környezetváltások, amelyek a teljesítmény csökkenéséhez vezethetnek. A vmstat kimenete így fest: procs ----------memory----------- --swap-- ---io---- --system-- ---cpu---r b swpd free buff cache si so bi bo in cs us sy id wa 18 8 0 5626196 3008 122788 0 0 330403 454 2575 4090 91 8 1 0 18 15 0 5625132 3008 122828 0 0 328767 322 2544 4264 91 8 0 0 17 12 0 5622004 3008 122828 0 0 327956 130 2406 3998 92 8 0 0 22 2 0 5621644 3008 122828 0 0 327892 689 2445 4077 92 8 0 0 23 5 0 5621616 3008 122868 0 0 323171 407 2339 4037 92 8 1 0 21 14 0 5621868 3008 122868 0 0 323663 23 2418 4160 91 9 0 0 22 10 0 5625216 3008 122868 0 0 328828 153 2934 4518 90 9 1 0

A vmstat az alábbi, memóriával kapcsolatos adatokról nyújt tájékoztatást: • A memory részben a lemezre kihelyezett memória (swpd), a szabad memória (free), az I/O adatszerkezet átmeneti tárának (buff) és a fájlolvasó gyorsítótárnak (cache) a méretét kapjuk meg kilobájtban.

IBM04.qxd

3/22/2006

1:09 PM

Page 71

4. fejezet • Rendszerteljesítmény-mérés • A swap részben a másodpercenként lemezre kihelyezett (so), illetve onnan beolvasott (si) kilobájtok számát találjuk. • Az io részben a különbözõ eszközökrõl másodpercenként beolvasott (bi) és kiírt (bo) blokkok méretét kapjuk meg kilobájtban. A sok I/O mûveletet végzõ feladatok esetében a bi és bo értékek képet adnak az átvitel sebességérõl, az in pedig a megszakítások gyakoriságáról tájékoztat. Az swpd, si és so értékébõl a memória lemezre való kihelyezésérõl kapunk képet. A processzorkihasználtság mellett legtöbbször az us, sy, id és wa értékére lesz szükségünk. Ha a wa túl magas, meg kell vizsgálnunk az I/O alrendszert. Elképzelhetõ, hogy a vizsgálat eredménye az lesz, hogy az I/O mûveletekre történõ várakozás idejét csak újabb I/O vezérlõk, illetve lemezek beüzemelésével csökkenthetjük.

I/O kihasználtság Bár a processzorsebesség, a memóriaméret és az I/O rendszerek sebessége folyamatosan növekszik, az I/O sebessége továbbra is nagyságrendekkel elmarad a memória sebességétõl. Ráadásul, mivel az alkalmazások egyre komolyabb I/O tevékenységet végeznek, az I/O könnyen az alkalmazások válaszidejének szûk keresztmetszetévé válhat. Az ilyen esetekben a teljesítményelemzõnek olyan eszközökre van szüksége, amelyekkel közelebbrõl is szemügyre veheti az I/O alrendszert. Ebben a részben elõször a lemez I/O mûveletekkel foglalkozunk. Ez után áttérünk a memória I/O vizsgálatára, mivel ehhez másféle eszközökre lesz szükségünk. A lemez I/O mûveleteknél a teljesítményt általában az áteresztõképesség és a késleltetés függvényében vizsgáljuk. A lemezek általában hatékonyabban kezelik a nagyméretû, egymás után következõ adatblokkokat, mint a kis, véletlenszerûen elhelyezkedõ blokkokat. A nagyméretû blokkok egyben történõ olvasásakor, illetve írásakor alkalmazhatók az olyan megoldások, mint az elõreolvasás vagy a hátraírás, a tároló rendszernek kevesebb fejmozgatást kell végeznie, és teljes sávokat írhat, amikor ez lehetséges. Sok alkalmazás azonban eltérõ, gyakran elõre nem látható helyeken nyúl hozzá a lemezhez. Ennek eredményeképpen a különbözõ feladatok I/O mûveleteiben az egymást követõ és a véletlenszerû blokkelérések váltakoznak, sõt még a blokkok mérete sem állandó. Amikor egy rendszer I/O teljesítményét vizsgáljuk, sok mindent észben kell tartanunk. Az elsõ és talán a legnyilvánvalóbb (bár gyakran megfeledkezünk róla), hogy az I/O teljesítmény nem lépheti át a hardver korlátait. Bár ezzel a kérdéssel részletesen foglalkozunk majd, az I/O áteresztõképességének és késleltetésének vizsgálatában sokat segíthet, ha tisztában vagyunk a hardver lehetõségeivel. A tárolóeszközök teljesítményét, az eszközöket összekapcsoló I/O buszokat (például SCSI, Fibre Channel), a tárolóeszköz felépítését (például Fibre Channel Switch), a buszcsatolókat, a rendszereket összekapcsoló buszokat

71

IBM04.qxd

72

3/22/2006

1:09 PM

Page 72


(például PCI, PCI-X és Infiniband), sõt bizonyos esetekben a rendszer felépítését is (például a buszcsatolók DMA elérése, NUMA kapcsolatok) is figyelembe kell venni az I/O alrendszer vizsgálatakor. Az összetettebb rendszerek esetében érdemes listát készíteni az eszközök sebességérõl és áteresztõképességérõl, hogy könnyebben elkülöníthessük egymástól a hardver és a szoftver okozta szûk keresztmetszeteket. A szoftver szûk keresztmetszeteinek és azok teljesítményre gyakorolt hatásának megértéséhez két dolgot kell figyelembe venni: az I/O adatátvitel sávszélességét és az egyes I/O kérések késleltetését. Ideális esetben a rendszer az optimális adatátvitel biztosítására törekszik. Mivel azonban az egyes kérések késleltetése a processzor sebességéhez mérten egészen nagy lehet, az alkalmazásoknak sokszor várniuk kell az I/O mûveletek eredményére. Vegyük például egy alkalmazást, amely egy olyan blokkot olvass, amely a következõ adatblokk elérésével kapcsolatban ad útmutatást. Ha a rendszer vagy az alkalmazás nem képes optimális módon végrehajtani ezt, a teljesítményt az I/O alrendszerre történõ folyamatos várakozás határozza meg. A probléma egyik gyakori megoldása, hogy a hasonló mûveleteket egymással párhuzamosan végzi a rendszer. A feladatok párhuzamos ütemezésével az operációs rendszer, illetve az alkalmazás egy idõben több hosszabb ideig tartó I/O kérést indíthat még akkor is, ha ezzel több alkalmazás is várakozásra kényszerül. Ezzel a módszerrel nagyon jól kihasználhatjuk az I/O alrendszer lehetõségeit. Annak ellenére, hogy az operációs rendszer és az alkalmazások célja minden esetben a rendszer optimális teljesítményének elérése, mindez nem mehet a felhasználói várakozási idõ rovására. Az I/O alrendszer válaszidejét jelentõsen befolyásolja, hogyan érkeznek a bejövõ kérések. Ha például a lemez I/O kérések egyszer a lemez elejérõl, egyszer pedig a lemez végérõl akarnak olvasni, a fizikai lemezben folyamatosan dolgoznia kell a fejmozgató karnak. Ez a fajta adatelérés lelassítja az adatokhoz való hozzáférést, azaz kevesebb mûveletet végezhetünk el ugyanannyi idõ alatt. Ráadásul ez nem csak a logikai meghajtó elérését lassítja, hanem az egész I/O alrendszer mûködését hátráltatja. Párhuzamos folyamatok esetén gondoskodni kell arról, hogy az alkalmazástól és az operációs rendszertõl érkezõ I/O kérések egyenletesen oszoljanak el a lemezek között. Az I/O kérések lemezek közötti elosztásával elért párhuzamosság tovább csökkenti az egyes lemezmeghajtók késleltetésébõl adódó teljesítményproblémákat. Az adatok megfelelõ módon történõ elosztásához alaposan ismerni kell az alkalmazást, és tisztában kell lenni azzal, milyen módon használja a lemezre írt adatokat. Bár a rendszerfigyelõ eszközök nem képesek nyomon követni minden egyes I/O kérést, vannak olyan eszközök, amelyekkel információt kaphatunk a rendszer által feldolgozott összes I/O mûveletrõl, ezeknek az egyes logikai meghajtók közötti megoszlásáról és az I/O alrendszer sebességérõl. A következõ részekben két eszközt mutatunk be: iostat (1) és sar (1). Ezek az eszközök segítenek az I/O szûk keresztmetszeteinek felkutatásában, megtudhatjuk, mely lemezek kevéssé használtak, és milyen késleltetésekkel kell számolnia a rendszernek (nem az alkalmazásnak!) az I/O mûveletek végrehajtása során.

IBM04.qxd

3/22/2006

1:09 PM

Page 73

4. fejezet • Rendszerteljesítmény-mérés Mielõtt ezekre az eszközökre rátérnénk, jegyezzük meg, hogy az I/O alrendszer teljesítményét számtalan módon növelhetjük. Léteznek tisztán hardveres megoldások (például nagyobb fordulatszámú lemezek használata, nagyobb gyorsítótár a lemezen, nagyobb gyorsítótár az I/O vezérlõn stb.). Ide tartozik még az írási és az olvasási sebesség növelése, az I/O buszok és összeköttetések sebességének növelése, ami az átviteli sebesség növelése mellett az I/O mûveletek késleltetését is csökkenti. Bizonyos lemezek és lemeztároló alrendszerek esetében egyetlen lemezzel is végezhetünk párhuzamos I/O mûveleteket, ami szintén megnöveli az I/O áteresztõ képességét. A hardver és a szoftver alapú RAID megoldásokkal szintén az I/O párhuzamosságát növelhetjük. A következõkben bemutatandó eszközök segítenek a megfelelõ hardveres és szoftveres megoldás kiválasztásában, illetve az adatok legmegfelelõbb elhelyezkedésének meghatározásában.

iostat Az iostat parancs annak tükrében vizsgálja az I/O mûveleteket, hogy a fizikai lemezek aktivitásának idõtartama milyen arányban áll az átlagos átviteli idõkkel. Az iostat paranccsal elkészített jelentés alapján megtervezhetjük például, hogyan oszthatjuk el optimálisan az I/O terhelést a lemezek között. Az iostat(1) ezen kívül a processzor kihasználtságáról is tájékoztat, amit idõnként hasznos közvetlenül is összevetni az I/O tevékenységekkel. Ha nem adunk meg intervallumot, az iostat a rendszer utolsó indítása óta gyûjtött adatokat használja. Ha idõintervallumot is megadunk, akkor az elsõ adathalmaz a rendszerindítás óta gyûjtött, a második pedig a megadott idõtartamra esõ I/O mûveleteket összegzi. Az alábbiakban látható adatok úgy születtek, hogy fájlokat másoltunk a /dev/sd0 és a /dev/sds7, a /dev/sdp7 és a /dev/sdt7, illetve a /dev/sdr7 és a /dev/sdu7 között: avg-cpu:

%user 0.21

%nice 0.00

%sys %iowait 0.80 2.07

Device: tps Blk_read/s Blk_wrtn/s sdx 0.00 0.00 0.00 sdw 0.00 0.00 0.00 sdv 0.00 0.00 0.00 sdu 2.49 0.05 1443.46 sdt 4.94 0.10 2871.73 sds 4.95 0.10 2860.91 sdr 30.20 1518.55 0.42 sdq 60.25 2902.76 0.92 sdp 0.00 0.01 0.00 sdo 59.49 2883.87 0.90

%idle 96.92

Blk_read 32 32 32 2778 5322 5330 83690898 159978258 378 158937034

Blk_wrtn 0 0 0 79552392 158268008 157671720 23288 50896 24 49520

73

IBM04.qxd

74

3/22/2006

1:09 PM

Page 74


Az iostat a processzorhasználatról a top-nál megszokott módon tájékoztat. Ez után a lemezhasználatról szóló jelentés következik. A fejléc után az egyes lemezek statisztikái következnek, ahol minden sor egy logikai lemez adatait írja le. A tps oszlop a logikai lemezhez címzett I/O kérések számát jelenti. Az I/O kérések méretérõl azonban semmit sem tudunk meg. A Blk_read/s és a Blk_wrtn/s a másodpercenként a lemezrõl beolvasott, illetve oda kiírt adatok mennyiségét adja meg. A blokkméretrõl itt sem tudunk meg semmit. Végül a Blk_read és a Blk_wrtn a logikai lemezre írt, illetve onnan beolvasott összes blokk számát jelzi (blokkméret nélkül). A –k kapcsolóval kilobájtban kaphatjuk meg ugyanezeket az adatokat, a –p segítségével partíciókra bontva jeleníthetjük meg õket, az –x pedig olyan további adatokat szolgáltat, mint az átlagos várakozási idõ és a kiszolgálás átlagos ideje. A fenti példában az sdo eszköz Blk_read értéke nagyon közel van az sds Blk_wrtn értékéhez, mivel az sdo7-rõl az sds7-re másoltunk adatokat. Ezen kívül az olvasási sebesség egy kicsivel nagyobb az írási sebességnél. A jelentés fényt derít az I/O szûk keresztmetszeteire (ha vannak ilyenek), és segíthet az adatbázisok tervezõinek abban, hogy úgy rendezhessék el adataikat, hogy azokat hatékonyan lehessen párhuzamosan olvasni.

sar A sar a sysstat csomag része, és az operációs rendszer számos különféle tevékenységérõl gyûjt és jelenít meg adatokat. Tájékoztatást kapunk például az I/O mûveletekrõl, a processzor kihasználtságáról, a környezetváltások és a megszakítások számáról, a lapok lemezre írásának és visszaolvasásának mértékérõl, a megosztott memória, az átmeneti tár és a hálózat használatáról. A sar indításakor paraméterként adhatjuk meg, milyen idõközönként és mennyi idõn keresztül szeretnénk jelentéseket kérni. A sar -b 3 12 parancs például 3 másodpercenként frissíti az adatokat összesen 12 másodpercen keresztül. Az adathalmaz végén átlagokat is találunk. A sar szolgáltatásokban igen gazdag eszköz. A következõkben ezekbõl a szolgáltatásokból mutatunk be néhányat: • A sar az iostat-hoz hasonló I/O statisztikákat ad. Megtudhatjuk az összes I/O mûvelet számát (tps), amit olvasási (rtps) és írási (wtps) mûveletek szerinti bontásban is megkapunk. A bread/s és a bwrtn/s részben az olvasási és írási mûveletek sebességérõl tájékozódhatunk. Az alábbi példában 2 másodpercenként kértünk adatokat 18 másodpercen keresztül. Az adatok alatt megtaláljuk mind az öt mezõ átlagát. A logikai meghajtók mûveleteit nem adtuk meg. 12:59:15 12:59:17 12:59:19 12:59:21 12:59:23 12:59:25 12:59:27

tps 37.50 66.50 268.50 333.50 153.50 133.00

rtps 37.50 66.50 268.50 261.50 40.50 5.00

wtps 0.00 0.00 0.00 72.00 113.00 128.00

bread/s 396.00 16140.00 66560.00 64548.00 9728.00 1024.00

bwrtn/s 0.00 0.00 0.00 9620.00 27984.00 31744.00

IBM04.qxd

3/22/2006

1:09 PM

Page 75

4. fejezet • Rendszerteljesítmény-mérés 12:59:29 12:59:31 Average:

119.50 133.00 155.63

7.50 5.00 86.50

112.00 128.00 69.13

1536.00 1024.00 20119.50

27776.00 31744.00 16108.50

• A sar processzoronként és a teljes rendszerre vetítve egyaránt képes tájékoztatást adni a processzorhasználatról. Ez a szolgáltatás elsõsorban a többprocesszoros rendszerekben hasznos. A számokból azonnal kiderül, ha egyes processzorokon nagy a terhelés, másokon pedig kicsi. Ilyenkor nekiláthatunk kideríteni, hogy a processzorterhelések közötti eltéréseket például az alkalmazás vagy a rendszermag okozza-e. Az alábbi adatok egy négyprocesszoros SMP rendszerbõl származnak: 11:09:13 11:09:18 11:09:18 11:09:18 11:09:18 11:09:18 11:09:23 11:09:23 11:09:23 11:09:23 11:09:23 . . . Average: Average: Average: Average: Average:

CPU all 0 1 2 3 all 0 1 2 3

%user 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

%nice 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

%system 4.70 5.80 4.80 6.00 2.40 3.75 5.39 2.80 5.40 1.40

%iowait 52.45 57.00 49.40 62.20 41.12 47.30 37.33 41.80 41.60 68.60

%idle 42.85 37.20 45.80 31.80 56.49 48.95 57.29 55.40 53.00 30.00

all 0 1 2 3

0.00 0.00 0.00 0.01 0.00

0.00 0.00 0.00 0.00 0.00

4.22 8.32 2.12 4.16 2.29

16.40 24.33 14.35 12.07 14.85

79.38 67.35 83.53 83.76 82.86

• A sar processzoronkénti bontásban tájékoztat a megszakításokról is: 10:53:53 10:53:58 10:53:58 10:53:58 10:53:58 Average: Average: Average: Average:

CPU i000/s 0 1000.20 1 0.00 2 0.00 3 0.00 0 999.94 1 0.00 2 0.00 3 0.00

i001/s 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

i002/s 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

i003/s i004/s 0.40 0.00 0.00 0.00 0.00 1156.00 0.00 0.00 1.20 590.99 0.00 0.00 0.00 466.51 0.00 0.00

i005/s 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

i006/s i007/s 3.00 0.00 0.00 2320.00 0.00 0.00 0.00 0.00 3.73 0.00 0.00 926.61 0.00 1427.48 0.00 0.00

A megszakítások eloszlásának tanulmányozásával a megszakítások feldolgozásának egyenlõtlenségeit fedhetjük fel. Az ilyen jellegû problémák egy lehetséges megoldása, ha adott megszakítások feldolgozását meghatározott processzorokhoz rendeljük. Ha például

75

IBM04.qxd

76

3/22/2006

1:09 PM

Page 76


a /proc/irq/ID fájlban a 0x0001 értéket helyezzük el, ahol az ID az eszközt jeleni, ennek az eszköznek a megszakításait kizárólag a 0-s processzor dolgozza majd fel. Ha ehelyett a 0x000f értéket használjuk, a megszakítást a 0–3. processzorok bármelyike megkaphatja. Egyes feladattípusok esetében ezzel a megoldással enyhíthetjük a legelfoglaltabb processzorok terhelését. Az I/O megszakítások kezelésének hatékonyabbá tétele az I/O teljesítményében is tükrözõdik.

Hálózatkihasználtság A hálózatok elterjedésével a számítógépes hálózatok külön szakterületté nõtték ki magukat. A kormány, a magáncégek és a tömegkommunikációs eszközök egyaránt az Internetre támaszkodik. A Világháló, az elektronikus levelezés, az azonnali üzenetküldés stb. közelebb hozták egymáshoz az embereket, mivel egymástól addig távol lévõ országok soha nem látott közelségbe kerültek. Népszerûvé váltak a keresõmotorok, amelyek néhány gombnyomásra a másodperc töredéke alatt szolgáltatják a keresett információt. Az elektronikus kereskedelem új színt hozott a kereskedelembe. Az emberek anélkül vásárolhatnak, intézhetik banki ügyeiket, kereskedhetnek részvényeikkel, játszhatnak távoli partnerekkel, dolgozhatnak közös munkákon, hogy fel kellene állniuk a helyükrõl. Mindezeket a gyors és nagy sávszélességû hálózatok megjelenése tette lehetõvé. Ezek hatására új számítógépes rendszerek fejlõdtek ki; ilyenek például a fürt felépítésû hálózatok és a tárolóhálózatok. Tanenbaum könyve nagyon jól átfogja ennek a területnek a legfontosabb témáit, például a TCP/IP protokollt, a körzet- és csomagváltást, a vezeték nélküli kapcsolatokat, a biztonságot, illetve a hang- és adattovábbítást. A Linux azon felül, hogy a hálózatkezelés terén a többi nagy operációs rendszeréhez hasonló színes szolgáltatáskészletet biztosít, jó néhány olyan képességgel is rendelkezik, amelyekkel a többiek nem. A Linux rendszermag számos hálózati protokollt ismer, ilyen például a TCP/IP, az IPX (Internetwork Packet Exchange) és az AppleTalk DDP, ezen kívül pedig támogatja az olyan szolgáltatásokat, mint a csomagtovábbítás, a tûzfalmûveletek, a helyettes vagy köztes kiszolgálók (proxy), a maszkolás, a csatornázás és a másodnevek (alias) használata. Linuxon számos, a hálózat teljesítményének értékelésére használható eszközt találunk. Ezek között akadnak olyanok is, amelyek a teljesítmény elemzése mellett a különbözõ hibák elhárítására is alkalmasak. A Linux rendszermag hatalmas mennyiségû hálózatkezeléshez kapcsolódó adatot bocsát a felhasználók rendelkezésére, amelyek segítségével folyamatosan figyelemmel kísérhetjük a hálózat mûködését, és felfedhetjük különféle hibáit. Ebben a részben mindössze néhány eszközt fogunk megnézni azok közül, amelyeket a legtöbb nagy Linux-kiadásban megtalálunk. A következõ eszközökrõl lesz szó: netstat, nfsstat, tcpdump, ethtool, snmp, ifport, ifconfig, route, arp, ping, traceroute, host és nslookup.

IBM04.qxd

3/22/2006

1:09 PM

Page 77

4. fejezet • Rendszerteljesítmény-mérés Ezek között vannak olyan eszközök, amelyekre a rendszergazdáknak nap mint nap szükségük van. A ping, a route, az arp, a traceroute, az ethtool és a tcpdump eszközöket a hálózati hibák felderítésére használhatjuk. Ezekrõl beszélünk most egy kicsit részletesebben: • A ping ipcím/gépnév parancs használatával kideríthetjük, hogy üzemel-e az adott gép, és elérhetõ-e a hálózaton keresztül. A ping az ICMP (Internet Control Message Protocol) protokoll Echo szolgáltatását használja. • A route parancsot az útválasztási táblázat megjelenítésére, új útvonalak felvételére, illetve a meglévõ útvonalak eltávolítására használhatjuk. • Az arp parancs olyankor jön jól, amikor a ping nem mûködik, azaz amikor a hálózati kapcsolat nem él. Ilyenkor az arp segíthet megtalálni a probléma gyökerét. Az arp –a paranccsal kideríthetjük, hogy a megfelelõ rendszerhez tartozik-e egy adott hardvercím. A további kapcsolók között találunk olyat, amelyikkel törölhetjük az arp gyorsítótárát, vagy éppen új elemeket adhatunk ahhoz. • Az IRRTToolset (Internet Routing Register Toolset) a hálózati mérnökök számára kényelmesebb és használhatóbb formában jeleníti meg az útválasztási adatokat. Az eszközök lehetõséget adnak az útválasztás automatikus beállítására, a szabályok elemzésére és a táblázatok karbantartására. • Az ifconfig az állomás médiahozzáférés-vezérlési címét adja meg. Ha egy másik, azonos IP címmel rendelkezõ gép is üzemel a hálózatban, elõfordulhat, hogy az arp gyorsítótárában a másik gép szerepel. Ilyenkor az arp paranccsal eltávolíthatjuk a gyorsítótárból a hibás címet, és hozzáadhatjuk a jót. • A traceroute a lehetséges hálózati utak egyikét térképezi fel. Megméri az útválasztási pontok közötti út megtételéhez szükséges idõt, és azonosítja az út során érintett útválasztók (router) címét. • Az ethtool az Ethernet eszközök beállításainak lekérdezésére és módosítására szolgál. Az eszközök azonosítót kapnak. Ha a rendszer n ilyen eszközt tartalmaz, akkor az eth0, eth1…ethn azonosítókat kapják. Az ethtool használatakor ezekkel az azonosítókkal hivatkozhatunk az eszközökre. • A tcpdump segítségével a hálózaton keresztülmenõ csomagokat hallgathatjuk le. A program minden csomagot észlel, ami a számítógép hálózati felületén áthalad. Segítségével megfigyelhetjük a hálózati forgalmat, felderíthetjük a protokoll hibáit és adatokhoz juthatunk. A tcpdump vegyes üzemmódba helyezi a hálózati felületet, hogy a vezetéken áthaladó összes csomaghoz hozzáférhessünk. A program számos kapcsolót kínál annak érdekében, hogy a számunkra érdekes csomagokat kiszûrhessük. A tcpdump hátránya, hogy a tár túlcsordulhat és körbefordulhat, a nagy sávszélességû hálózatok esetében így csomagokat veszíthetünk. A tcpdump nem minden esetben képes tehát lépést tartani a csomagok sebességével. • Az ethereal egy másik, a tcpdump-hoz hasonló hálózatfigyelõ eszköz. Az ethereal olvassa a tcpdump segítségével összeállított fájlokat.

77

IBM04.qxd

78

3/22/2006

1:09 PM

Page 78


• A host programmal egy adott IP címhez tartozó gép nevét kérdezhetjük le a DNS rendszertõl. Ez az eszköz rugalmasabb, mint az nslookup, és parancsfájlokban is jobban használható. • A Linux számos, a hálózati biztonsághoz kapcsolódó eszközt tartalmaz. Ilyen eszközök a snort (a hálózaton keresztül történõ behatolást észlelõ rendszer), a dsniff (egy hatékony hálózatellenõrzõ és behatolásérzékelõ eszközökbõl álló csomag) és a SAINT (System Administrator’s Integrated Network Tool).

Hálózati statisztika A net-tools csomag részét képezõ netstat segédprogram rengeteg, a hálózati alrendszerhez kapcsolódó adat megjelenítésére képes. A netstat a Linux kiszolgálókon a hálózati kapcsolatok megfigyelésére leggyakrabban használt eszközök egyike. A netstat listát készít az egyes protokollok (például TCP és UDP) elérhetõ csatolófelületeirõl (socket). Adatokat kapunk a hálózati útvonalakról, és összesített statisztikát a hálózati felületekrõl, többek között a bejövõ és kimenõ csomagok számáról és a csomagütközésekrõl. Az alábbi netstat-kimenetben több protokoll (például IP, TCP és UDP) hálózati statisztikáit és útválasztási adatait is megtaláljuk. Az adatokból kiderül, ha a fogadott és az elküldött csomagok száma a vártnál magasabb vagy alacsonyabb. Ezzel az eszközzel könnyen fényt deríthetünk rá, ha a rendszermag frissítésekor csökken a hálózat teljesítménye. Ha paraméterek nélkül futtatjuk, a netstat az összes csatolófelület adatait megjeleníti. Minden protokollcsalád megjelenik a listában, köztük a UNIX tartománycsatolók is. Az alábbi sorok a netstat kimenetébõl származnak: $ netstat Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address tcp 0 0 *:32768 *:* tcp 0 0 *:smux *:* tcp 0 0 *:9099 *:* tcp 0 0 *:sunrpc *:* tcp 0 0 *:x11 *:* tcp 0 0 *:http *:* tcp 0 0 *:ftp *:* tcp 0 0 *:ssh *:* tcp 0 0 *:telnet *:* tcp 0 0 nethostA:smtp *:* tcp 0 0 nethostA:32974 nethostB:ssh tcp 0 0 nethostA:32996 nethostB:ssh tcp 0 0 nethostA:33002 64.233.161.99:http tcp 0 0 nethostA:33005 nethostB:ftp udp 0 0 *:32768 *:*

State LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN LISTEN ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED

IBM04.qxd

3/22/2006

1:09 PM

Page 79

4. fejezet • Rendszerteljesítmény-mérés udp 0 0 *:snmp *:* udp 0 0 *:sunrpc *:* Active UNIX domain sockets (servers and established) Proto RefCnt Flags Type State I-Node unix 2 [ ACC ] STREAM LISTENING 2012 unix 2 [ ACC ] STREAM LISTENING 159792 ¯ ksocket-nivedita/kdeinit-:0 unix 2 [ ACC ] STREAM LISTENING 2210 unix 2 [ ACC ] STREAM LISTENING 79840 ¯ .ICE-unix/dcop15789-1077867386

Path /dev/gpmctl /tmp/ /tmp/.X11-unix/X0 /tmp/

Az elsõ oszlop a csatolófelülethez tartozó protokollcsaládot jelzi, ami általában tcp (transport control protocol), udp (user datagram protocol) vagy unix (UNIX domain socket). A második és a harmadik oszlopokban a csatolófelülethez tartozó kimenõ és bejövõ adatsorok méretét látjuk bájtban. A következõ oszlopokban a helyi és a távoli címet, illetve a kapu adatait olvashatjuk le. Az utolsó oszlop a csatoló protokoll szerinti állapotát jelzi. Az IP címek helyett általában a gépek neve jelenik meg, kivéve, ha a netstat-ot a –n kapcsolóval hívjuk meg. Kapcsolók segítségével jelezhetjük azt is, ha csak bizonyos protokollcsaládokra vagyunk kíváncsiak. A netstat –tcp vagy –t például csak a TCP csatolófelületek adatait jeleníti meg. Az egyes családokhoz tartozó kapcsolók teljes listáját megtaláljuk a netstat man oldalán. A csillag (*) tetszõleges karaktereket helyettesíthet. A helyi címeknél gyakran találkozhatunk vele, amennyiben a folyamat az összes helyi felületet figyeli. A távoli címek és kapuk adatai csak akkor jelennek meg, miután sikeresen felépítettük velük a kapcsolatot. Az elõzõ példában folyamatban lévõ ssh, http és ftp kapcsolatokat láthatunk.

Felületadatok megjelenítése Ebben a részben ugyanazokat az adatokat látjuk, mint az ifconfig kimenetében. A lista a felület által gyûjtött statisztikákat összegzi. Megtaláljuk ezek között az MTU-t (maximum transmission unit), illetve a sikeres, hibás, eldobott és túlcsordult csomagok számát. $ netstat –i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR eth0 1500 0 21941 0 0 0 lo 16436 0 795 0 0 0

TX-OK TX-ERR TX-DRP TX-OVR Flg 11998 0 0 0 BMRU 795 0 0 0 LRU

79

IBM04.qxd

80

3/22/2006

1:09 PM

Page 80


TCP/IP protokollstatisztikák A Linux rendszermag az SNMP (Simple Network Management Protocoll) MIB (Management Information Base) részeként megadott RFC 2012-ben felsorolt statisztikai számlálókat támogatja. Ezen kívül számos, kizárólag a Linuxra jellemzõ statisztikát is biztosít, és képes elfogni a hálózati protokollokhoz (elsõsorban TCP) kapcsolódó eseményeket. A netstat segédprogram a rendszermagban rendelkezésre álló számlálók nagyobb részét képes megjeleníteni, de nem az összest. Ha a teljes listát szeretnénk látni, nézzünk bele a /proc/net/snmp és a /proc/net/netstat fájlokba. Az elõbbi az RFC 2012 számlálóit, az utóbbi pedig a Linuxra jellemzõ MIB-adatokat tartalmazza. Az alábbiakban a netstat –s parancs kimenetére látunk példát: netstat -s Ip: 662968 total packets received 0 forwarded 0 incoming packets discarded 659592 incoming packets delivered 162297 requests sent out Tcp: 5721 active connections openings 39 passive connection openings 0 failed connection attempts 0 connection resets received 1 connections established 136759 segments received 152791 segments send out 20660 segments retransmited 3 bad segments received. 1165 resets sent Udp: 14031 packets received 15 packets to unknown port received. 0 packet receive errors 7519 packets sent

A hálózaton keresztül történõ kapcsolattartáshoz komoly megszakításkezelés is kapcsolódik. A megszakítások számát a vmstat, a megszakítások feldolgozásának eloszlását pedig a sar kimenetében találjuk meg.

IBM04.qxd

3/22/2006

1:09 PM

Page 81


nfsstat Az NFS (Network File System, hálózati fájlrendszer) olyan megoldás, amellyel a távoli gépek fájlrendszereit az adott gép fájlrendszerének részévé tehetjük. Az NFS segítségével tehát a távoli és a helyi fájlokat ugyanazon az írási és olvasási felületen keresztül érhetjük el. Az nfsstat egy egyszerû eszköz, amely a rendszermag NFS-hez kapcsolódó statisztikáit jeleníti meg. Az nfsstat összegyûjti az NFS felületén keresztülmenõ hívások számát. A következõ példában a kiszolgáló egy I/O mûveleteket is tartalmazó feladatot futtat. Az nfsstat kimenetébõl leolvashatjuk az írások és az olvasások számát, amit azután hibakeresésre használhatunk. Az olvasási és írási mûveletek száma a teljesítményproblémák megértésében is a segítségünkre lehet. Server nfs v3: null getattr setattr 0 0% 8 0% 0 0% read write create 262242 44% 328004 55% 2 0% remove rmdir rename 3 0% 0 0% 0 0% fsstat fsinfo pathconf 1 0% 1 0% 0 0%

lookup 6 mkdir 0 link 0 commit 2586

access readlink 0% 43 0% 0 0% symlink mknod 0% 0 0% 0 0% readdir readdirplus 0% 0 0% 0 0% 0%

Összefoglalás A fejezet során számos, a Linux teljesítményéhez kapcsolódó eszközt megismertünk. Találkoztunk a processzor, a memória, az I/O alrendszer és a hálózat teljesítményének elemzéséhez kapcsolódó segédprogramokkal is. Ezeknek az eszközöknek a birtokában pontosabb képet kaphatunk arról, milyen rendszererõforrásokat használnak a különbözõ feladatok. A bemutatott eszközök egy része a felhasználó terében történõ rendszertevékenységek felfedésére is alkalmas. A fejezetben kitértünk rá, mit jelentenek ezek az adatok, és mire használhatja azokat egy rendszerelemzõ. A legtöbb szolgáltatást, amelyekre a teljesítmény elemzése során szükségünk lehet, ezek az eszközök biztosítják számunkra. Ha azonban olyan tevékenységeket szeretnénk feltérképezni, mint a folyamatok átültetése vagy a NUMA rendszerek csomópontjai között történõ távoli memóriaelérés, akkor más programokat is be kell szereznünk. Olyan eszközökre is szükségünk lesz, amelyek képesek az összegyûjtött adatokat többféle nézetben megjeleníteni, így könnyebben megérthetjük a rendszermag vagy a felhasználói alkalmazások mûködését. Egy ilyen eszköz például a gnuplot. Az adatokat többféle tömörségben is megjeleníthetjük, így alkalmazkodva a különbözõ adatsûrûségi szintekhez, különös tekintettel az összetett adatokkal dolgozó többszálú vagy SMP gépekre. A teljesítményelemzõ eszközök kulcsfontosságú szerepet játszottak abban, hogy a Linux a vállalati rendszerek világába léphetett.

81

IBM04.qxd

82

3/22/2006

1:09 PM

Page 82


Hivatkozások 1. gnuplot: http://www.gnuplot.org/. 2. gprof: http://sources.redhat.com/binutils/docs-2.12/ gprof.info/index.html. 3. Hinton, Glenn és mások: The Microarchitecture of the Pentium 4 Processor, http://www.intel.com/technology/itj/q12001/pdf/art_2.pdf 4. Luo, Yue és mások: Benchmarking Internet Servers on SuperScalar Machines (Computer, 2003. február, 34–40. o.) 5. Kernprof: http://oss.sgi.com/projects/kernprof. 6. netstat: http://www.ussg.iu.edu/usail/man/linux/netstat.8.html. 7. nfsstat: http://www.die.net/doc/linux/man/man8/nfsstat.8.html. 8. oprofile: http://oprofile.sourceforge.net/doc. 9. Performance Inspector: http://www-124.ibm.com/developerworks/ opensource/pi/. 10. Readprofile: http://nodevice.com/sections/ManIndex/man1303.html. 11. sysstat: http://perso.wanadoo.fr/sebastien/godard/. 12. strace: http://sourceforge.net/projects/strace. 13. Stallings, William: Computer Organization and Architecture – Designing for Performance (6. kiadás, Prentice Hall, 2003.) 14. tcpdump: http://www.die.net/doc/linux/man/man8/tcpdump.8.html. 15. top: http://nodevice.com/sections/ManIndex/man1818.html. 16. Intel VTune: http://www.intel.com/software/products/vtune/. 17. vmstat: http://nakula.rvs.uni-bielefeld.de/cgi-bin/ man.sh?man=8+vmstat. 18. Az Interneten: http://www.ping127001.com/pingpage.htm.

IBM04.qxd

3/22/2006

1:09 PM

Page 83

4. fejezet • Rendszerteljesítmény-mérés 19. Az Interneten: http://www.ethereal.com/docs/man-pages/ tcpdump.8.html. 20. Az Interneten: http://csrc.nist.gov/tools/tools.htm. 21. Az Interneten: http://www.ripe.net/ripencc/pub-services/ db/irrtoolset/. 22. Az Interneten: http://www.insecure.org/tools.html. 23. Tanenbaum, Andrew. Computer Networks, Third Edition. Prentice Hall, 1996.

83

IBM04.qxd

3/22/2006

1:09 PM

Page 84

A fejezetben bemutott eszközök az alábbi területek feltérképezésében segítenek:

Recommend Documents