Gyakran feltett kérdések

Teljesítmény, hangolás és optimalizálás (TID 2943356 és TID2943472)

Téma

Az TID 2943356 és a TID 2943472 a szerver teljesítményének optimalizálásával foglalkoznak. Egy részük a szerver megelző jellegű karbantartási feladatairól szól, valamint arról, hogyan érhető el a legjobb teljesítmény. Az alábbi tevékenységek végrehajtása csökkenti a szerverleállások és -összeomlások esélyét is.

A MONITOR.NLM és a kijelzett Utilization (kihasználtság) érték

A Monitor által kijelzett kihasználtsági (kihasználtság) érték nem teljesen pontos szám. Egyes szerverfolyamatok meghívják a CyieldWithDelay illetve CyieldUntilIdle nevű NetWare-funkciókat. Amennyiben egy programszál ezen funkciók valamelyikében tölti az idejét, úgy fog tűnni, mintha a szerver kihasználtsága rendkívül magas lenne. A kihasználtsági érték tehát pontatlan lesz.

Ne ijedjünk meg akkor sem, ha a kihasználtság egy pár másodpercre felugrik 100 százalékra, majd utána újra leesik. 4.10-es szerverek esetében ez egy teljesen normális jelenség.

Az operációs rendszer javításai és más NLM-frissítések

Telepítse MIND A 410PTx.EXE, mind a 410ITx.EXE javításokat. Ezek a szoftverjavítások a magas kihasználtsági értékekkel kapcsolatos és néhány más problémát javítanak ki. Az összes szoftverjavítás telepítése csökkenti a jövőbeni problémák valószínűségét.

IntranetWare vagy NetWare 4.11 esetében használjuk az IWSPx.EXE nevű fájlt. NetWare 5 esetében használjuk az NW5SPx.EXE fájlnevű NW%-szervizcsomagokat. A szervizcsomagok nemcsak az OS-szoftverjavításokat tartalmazzák, hanem a szerver-NLM-ek összes szükséges frissítését és kiegészítését is.

(A jelen TID legutolsó áttekintésekor lévő legutolsó NW410 szoftverjavítás-változat a 410PT8B.EXE, a legfrissebb Service Pack pedig az IWSP6.EXE.)

Az OS-szoftverjavítások a SERVER.NLM-mel és a LOADER.EXE-vel kapcsolatos problémákat javítják ki. Az újabb csomagokban ezeken kívül vannak a kibocsátott NLM-ekhez is (pl. a CLIB.NLM-hez) való javítások is, amelyek más, szintén a magas kihasználtsághoz vezető problémákat oldanak meg.

Az új frissítések ki is bővítik a korábbi változatokat. Célszerű mindig telepíteni a legfrissebb változatokat a szerverre.

A legfrissebb szoftverjavításokkal és frissítésekkel kapcsolatban kérjük, forduljon a support.novell.com webhelyhez. Célszerű telepíteni a http://support.novell.com/misc/patlst.htm címen megtalálható "minimális szoftverjavítás"-listában felsorolt összes legfrissebb javítást.

Ezenkívül használja mindig a hardvergyártótól származó legfrissebb hálózati és lemezmeghajtó-programokat.

Az NDS és a DS.NLM

Frissítse a DS-t a 4.89a vagy későbbi változatra az NW4.10 használata esetében. A Novell Support találkozott már olyan esettel, ahol a DS okozta a magas kihasználtságot, a 4.89a viszont megoldja az összes ilyen problémát. (A jelen TID legutolsó áttekintésekor lévő legutolsó DS.NLM-változat NW410 esetében az 5.15, NW411 esetében pedig a 6.02.)

Alapvető fontosságú a megfelelő faterv, particionálás és replikáció a kihasználtsági problémák elkerülése érdekében. A partícióreplikák mérete, típusa és száma helytelen felügyelet esetén vezethet kihasználtsági problémákhoz. Ellenőrizzük azt is, összesen hány NDS-objektum található az adott szerver partícióiban. A DS-nek fenn kell tartania a replikagyűrű összes szervere között a szinkronizációt. Mennél több replikája van egy partíciónak, annál nagyobb lesz a hálózati forgalom. A Novell azt ajánlja, legalább három replikát tartsunk a címtárfa minden egyes partíciójáról. Ez megfelelő hibatűrést biztosít, és lehetővé teszi a DS helyreállítását, amennyiben az adatbázis megsérül.

Szolgáltatásfolyamatok (service processes)

A szolgáltatásfolyamatok olyan programszálak, amelyek a bejövő szolgáltatáskéréseket szolgálják ki.

A NetWare 4.x maximum 1000 szolgáltatásfolyamatot képes biztosítani. Maximalizáljuk a szolgáltatás-folyamatokat kapcsolatonként 2-3-ra. Ajánlott beállítani a Maximum Service Processes (szolgáltatásfolyamatok maximális száma) paraméter értékét 1000-re (a lehetséges maximumra) beállítani. Amennyiben a szervernek nincsen szüksége további szolgáltatásfolyamatra, akkor nem foglal le többet. Beállíthatjuk az új szolgáltatásfolyamatok várakozási idejét 0,3-ra (az alapértelmezés 2,2).

A szolgáltatásfolyamatokkal kapcsolatos további részletek, valamint az, hogyan lehet megnövelni a of szolgáltatásfolyamatok számát a kívánt értékre, a http://support.novell.com/cgi-bin/search/PATLSTFIND.CGI?2941108,HIGHUTL1.EXE címen olvashatók.

Upgrade Low Priority Threads (alacsony prioritású szálak frissítése)

Ellenőrizzük, hogy az UPGRADE LOW PRIORITY THREADS paraméter OFF-ra van állítva. Ha ON-ra van állítva, akkor hozzájárulhat a szerver kihasználtsági problémáihoz. NW5-szerverek esetében ennek a paraméternek nincsen jelentősége.

LRU Sitting Time (LRU lecsúszási idő)

A NetWare fájlhozzáférés-gyorsító alrendszere négykilobájtos memórialapok egy halmazából, az ún. "pool"-ból áll. Az operációs rendszer, a rendszer és az alkalmazások NLM-jeinek betöltése után a NetWare az összes maradék memóriát fájlgyorsításra foglalja le. A lista eleje vagy "feje" (list head), az a pont, ahol az új cache-puffereket a listába beillesztjük. A lista vége vagy "farka" (list tail), az a pont, ahonnét a régi cache-puffereket kitöröljük a listából. A lista minden egyes cache-puffere kapcsolódik a következő cache-pufferhez, és mindegyiknek része egy időbélyeg, amelyik azt jelzi, mikor került az adott cache-puffer a lista elejére.

Amikor a szerver egy olyan adattal kapcsolatos I/O-kérést kap, amelyik éppen nem található a cache-ben (ez az ún. "cache miss", "nem talált"), akkor az adat kiolvasódik a lemezről, és a lista legvégéről levett egy vagy több cache-pufferbe íródik. Minden egyes újonnan megtöltött cache-puffer kap egy, az aktuális időt jelző időbélyeget, és beszúródik a lista elejére. Az újonnan megtöltött cache-puffer a legfrissebben használt (most-recently-used, MRU) cache-puffernek számít, lévén ez tartózkodott a legrövidebb ideig a cache-ben.

A NetWare-környezetekben gyakran előforduló "cache hit", azaz "találat" az az esemény, amikor a szerver képes a lemezzel kapcsolatos olvasási kérést a lemez helyett közvetlenül a cache-ből kiszolgálni. Ebben az esetben, a kérés kiszolgálása után a kért adatokat tartalmazó cache-puffer törlődik a lista végéről, az aktuális időt jelző időbélyeget kap és visszaszúródik a lista elejére. E rendszerben a legfrissebben használt cache-pufferek a lista elején gyűlnek. Fontos, hogy megértsük a lista ezen jellegzetességét, hiszen a cél az, hogy a legfrissebben használt cache-pufferek a cache-ben maradjanak a várható további, ismételt felhasználás és találat érdekében.

E folyamat valamely részén a pool egy idő után betelik frissen használt adatokkal. E ponton nyer értelmet a legrégebben használt (least-recently-used, LRU) cache-puffer. Az LRU cache-pufferek azok a pufferek, amelyek meg lettek töltve a lemezről származó adatokkal, ám nem használták őket olyan sűrűn, mint a lista fejénél található MRU cache-puffereket. Mivel az MRU cache-puffereket mindig a lista fejéhez szúrjuk vissza, az LRU cache-pufferek a lista farkánál gyűlnek fel. Amikor új cache-pufferekre van szükség a lemezről kért adatok tárolásához, a NetWare törli a szükséges számú LRU cache-puffert a lista végéről, megtölti őket az újonnan kért adatokkal, az aktuális időre módosítja az időbélyeget, és visszaszúrja őket a lista elejére.

Mindennek eredményeképpen a NetWare fájlhozzáférés-gyorsító alrendszere előnyben részesíti a gyakran kért adatokat, és a ritkábban használt adatokat csak addig tartja a memóriában, amíg arra nincsen szükség más, gyakrabban kért adathoz.

A cache teljesítményének hangolásakor tehát az ideális megoldás, ha minden ismételten használt, frissen hozzáfért adat kiszolgálható a cache-ből. Ez úgy érhető el, hogy a szerver memóriáját úgy méretezzük, hogy a létrejött cache pool elég nagy lesz ahhoz, hogy az összes ismételten kért adatot ki tudja szolgálni.

Az LRU Sitting Time (LRU lecsúszási idő) statisztikát a rendszer úgy számolja, hogy megnézi az aktuális idő és a lista végén található LRU cache-blokk időbélyegének a különbségét. Az LRU Sitting Time azt az időt méri, amíg egy, a lista elején található MRU cache-puffer leér a lista legaljára, azaz LRU cache-puffer lesz belőle. Tekinthető ez az érték a cache egyfajta "felkavarási állandójának" is, hiszen - akár találatok, akár nem találatok miatt, de - ennyi időn belül a lista összes cache-puffere újrafelhasználódik. Ellenőrizzük, hogy az LRU Sitting Time paraméter nem csökken 15 perc alá. Amennyiben így lenne, további memóriára lehet szükség.

Physical Packet Receive Buffers (fizikai csomagfogadó pufferek)

A fogadópufferek tárolják átmenetileg a NetWare-szerverhez kapcsolódó hálózatokról érkező csomagokat. A Maximum Physical Receive Packet Size (fizikai csomag mérete) paramértert a hálózatnak megfelelően kell beállítani: Ethernet-szegmensek esetében a legtöbb esetben 1524, Token Ring és FDDI esetében 4540, Arcnet és LocalTalk esetében pedig 618 bájtra. Ezek a számok a "Novell BorderManager Installation és Setup" (Novell BorderManager telepítés és beállítás) c. kézikönyvből, az "Installing Novell BorderManager" (Novell BorderManager telepítése) c. fejezetből, a 9. oldalról származnak. Egyes telepített termékek egyedi beállításokat követelhetnek meg, amely esetben forduljon a kézikönyvhöz a részletekkel kapcsolatban.

Jó ökölszabály a fogadópufferek minimális számának beállításához 2-3 fogadópuffert számolni minden egyes kapcsolathoz, a maximális értéket pedig állítsuk 4000-re (vagy magasabbra).

Ezenfelül ellenőrizzük a MONITOR LAN/WAN Information ablakának No ECB (event control block, eseményvezérlő blokk) Available Count statisztikáját. Itt azt láthatjuk, hogy a szerver hányszor nem volt képes lefoglalni elegendő számú csomagfogadó puffer, régebbi nevén ECB-t. Az ECB-kből való kifogyás nem végzetes hiba. A már több napja komoly terhelés alatt futó szerverek ki-kifogynak az ECB-kből, és ilyenkor ECB-rendszerüzenetek generálódnak. Amennyiben ezeket a helyzetek csak ritkán, csúcsterhelés alatt fordulnak elő, akkor elegendő megtartani az aktuális ECB-beállításokat, és belenyugodni a ritka üzenetekbe. Ha viszont a szerver memóriaterhelése rendkívül magas, és gyakran ECB-lefoglalási hibákat kapunk, szinte bizonyosan célszerű a maximálisan lefoglalható ECB-k számát magasabbra állítani. Használjuk az alábbi SET parancsot az AUTOEXEC.NCF fájlban:

SET MAXIMUM PACKET RECEIVE BUFFERS = szám

Ne feledjük, hogy az ECB-k számára félretett memória más célra nem használható. A szerver által kezelhető pufferek minimális száma szintén beállítható a STARTUP.NCF fájlban, az alábbi paranccsal:

SET MINIMUM PACKET RECEIVE BUFFERS = szám

Amennyiben a Packet Receive Buffers paraméter értéke egy idő után meghaladja a szerver számára minimálisan beállított értéket, akkor állítsuk feljebb a Minimum Packet Receive Buffers értékét az aktuálisra.

Packet Burst

A Novell-tanácsadás számos olyan kihasználtsági problémával találkozott, amelynek oka a NetWare és Microsoft requester kliensek által használt packet burst protokoll volt. E problémák legnagyobb része megoldható egy operációsrendszer-frissítéssel, illetve egy új requesterprogrammal. Töltsük be a 410 OS-szoftverjavítást és szerezzük be a legújabb FIO.VLM-et, amelyik kijavítja a Novell requester hibáit. Az Internetről letöltendő fájl a VLMFX3.EXE. (A VLM aktuális verziója az 1.21)

Hibakeresés:

A Novell műszaki tanácsadásnak van egy PBRSTOFF.NLM nevű modulja, amelyik letiltja a szerveren a Packet Burstöt. A modult akkor kell betölteni, amikor a szerver feljön. Csak a modul betöltése után létrejött kapcsolatokon tiltható le a packet burst. Ez megoldást jelenthet a packet burst használatával kapcsolatos kihasználtsági problémákra.

Cache Buffers (cache-pufferek)

Amikor a szerver elindul, minden szabadon maradt memória fájlhozzáférés-gyorsításra tevődik félre. Amikor a többi erőforrás (pl. a könyvtárcache-pufferek) iránti igény megnövekszik, a rendelkezésre álló szabad fájl cache-pufferek száma csökken. Az operációs rendszer nem foglal le azonnal új helyet az új erőforrásoknak a kérés fogadásakor. Egy meghatározott ideig vár, hátha a meglévő erőforrások képesek kiszolgálni a kérést. Amennyiben ezen időn belül felszabadulnak erőforrások, úgy nem foglal le új erőforrásokat; ha nem szabadulnak fel, akkor igen. Az időkorlát biztosítja, hogy a hirtelen kiugrások ne eredményezzenek állandóra lefoglalt, ám valójában szükségtelen erőforrásokat.

Az operációs rendszer az alábbi paramétereket állítja dinamikusan:

Könyvtárcache-pufferek
Disk elevator (lemezolvasás-szervezés) méret
Fájlzárások
Kernelfolyamatok
Kernelszemaforok
A nyitott fájlok maximális száma
Memory for NLMs
Útválasztó/szerver hirdetése
Útválasztási pufferek
Szolgáltatásfolyamatok
TTS-tranzakciók
Turbo FAT indextáblák.

Általános vezérelvként ha a MONITOR Resource Utilization (erőforrás-kihasználtság) értéke 40% alá esik, akkor több memóriát kell tenni a fájlszerverbe. Ez a szabály jól működött hosszú évekig, amikor az átlagos rendszerek 16-32 megabájt memóriát tartalmaznak. A mai rendszerekben (százalékos arányban) már több cache-puffer áll rendelkezésre. Egy 32 megabájtos rendszer 40 százaléka 12 megabájt, ugyanakkor 1024 megabájt 40 százaléka már 409.

A legtöbb esetben látható a teljesítményesés, ha a cache-pufferek mennyisége 40% alá esik. A százalékkos érték az összes cache-pufferek és az eredeti cache-pufferek számának hányadosa. E két érték a MONITOR.NLM General Information képernyőjén látható. Az IntranetWare-szerver memóriájának optimalizálásával kapcsolatban forduljunk az 1997. márciusi AppNotes-hoz.

Rövid megjegyzés a finomhangolással kapcsolatban:

Mivel az erőforrások (pl. a memória) mennyisége minden szerveren valahol korlátozott (legalábbis amíg több memóriát nem tesznek bele), a szerver finomhangolása a korlátozott erőforrások és a szervernek a munkaállomások felé nyújtott teljesítménye közötti egyensúly megtalálásából áll. Vegyünk például egy csupán 64 megabájt memóriát tartalmazó szervert. Ha több memóriát foglalunk le könyvtárcache-puffereknek és csomagfogadó puffereknek, akkor kevesebb memória áll rendelkezésre fájlgyorsításhoz. Ha túl sok memóriát biztosítunk más erőforrások számára, akkor akár annyira lecsökkenhet a fájlgyorsításhoz használható memória, hogy a szerver nem gyorsabban fog működni, hanem lassabban. Ebben az esetben a könyvtárcache-pufferek és a csomagfogadó pufferek helyes mennyiségével kialakított egyensúly, amelyben elegendő memória jut a fájl cache-puffereknek is, jobb szerverteljesítményt eredményez, mint ha elégtelen számú, vagy éppen túlságosan sok memóriát foglalnánk le könyvtárcache-pufferek számára (figyelembe véve a szerver korlátozott erőforrásait).

Dirty Cache Buffers (módosított cache-pufferek) és Current Disk Requests (aktuális lemezkérések)

Az, ha a (MONITOR képernyőjén látható) Dirty Cache Buffers és Current Disk Requests értékek túl magasak, azt jelenti, hogy a lemezre kiírandó cache-pufferek, illetve a kiszolgálás alatt lévő lemezkérések száma túlságosan magas.

A Maximum Concurrent Directory Cache Writes (alapértelmezés szerint 10) és a Maximum Concurrent Disk Cache Writes (alapértelmezés szerint 50) értékeit az alapértelmezett érték fölé is állíthatjuk. Lecsökkenthetjük a Dirty Disk Cache Delay Time paramétert is az alapértelmezés alá (alapértelmezés szerint 3.3 Sec).

Egészen addig változtathatjuk a módosított cache-pufferek és az aktuális lemezkérések értékeit, amíg periodikusan nullára nem csökkennek. Az érték rövid időre meg-megugorhat, de vissza kell térnie 0-ra. Ha a módosítások után a módosított cache-pufferek és az aktuális lemezkérések értéke még mindig magas, akkor a lemezek nem képesek lépést tartani a terheléssel. Ebben az esetben vagy gyorsabb lemezegységeket kell beépíteni, vagy pedig meg kell osztani a szerver terhelését. A lemezegység az egyik leggyakoribb szűk keresztmetszet.

&Eeacute;rdemes lehet megpróbálni az alábbi beállításokat, és finomhangolni őket:

SET Maximum Concurrent Disk Cache Writes = 500
SET Dirty Disk Cache Delay Time = 0.5
SET Maximum Concurrent Directory Cache Writes = 100

Gazdagép-adapterek, tükrözés és kettőzés

Több eszköz konfigurálása esetén tanácsos a lassabb eszközöket a gyorsabbaktól elkülönítve, külön csatornára vagy gazdagép-adapterre tenni. A lassú eszközök például a szalagos meghajtók és a CD-olvasók. A gyors eszközök például a lemezmeghajtók.

Továbbá mindig hardveres tükrözést, kettőzést vagy RAID-et használjunk, ne szoftverest. A szoftveres tükrözés, kettőzés és RAID mindig lassabb, mint a hardveres megoldás.

A szerver sebessége számos tényezőtől függ, többek között a CPU-tól, a memória mennyiségétől és a merevlemez hozzáférési sebességétől. A szerver lusta válaszai utalhatnak például egy lassú merevlemezre.

Ellenőrizzük a "Dirty Cache Buffers" és a "Current Disk Requests" értékeket a MONITOR konzolján, és állapítsuk meg, hogy a merevlemez képes-e megbirkózni a hozzáférések okozta terheléssel.

Könyvtárhozzáférés-gyorsítás

A cache-memória működéséhez az alábbi feladatokhoz kell lefoglalni memóriát: a hash-táblához, a FAT-hez, a Turbo FAT-hez, a részallokációs táblákhoz, a könyvtárcache-hez, az átmeneti adattároláshoz a fájlok és NLM-fájlok kezelésekor, valamint egyéb funkciókhoz. A FAT és a DET a szervermemóriába íródik. A könyvtárbejegyzéseket tartalmazó gyorsítótárat nevezzük könyvtárcache-nek. A szerver a könyvtárcache-ből sokkal gyorsabban elő tudja keresni egy fájl címét, mintha ugyanezt lemezről kéne kikeresnie.

Állítsuk a könyvtárcache-pufferek minimális számát kapcsolatonként 2-3-ra, a maximális számát pedig 4000-re. &Eeacute;rdemes lehet beállítani a könyvtárcache-lefoglalás várakozási idejét 0,5 másodpercre (az alapértelmezés 2,2). Amennyiben - miután a szerver már egy ideje üzemel - a könyvtárcache-pufferek aktuális száma a minimális szint fölé emelkedik, állítsuk a könyvtárcache-pufferek minimális számát az aktuális szintre.

Blokk-részallokáció

A NetWare 4-ben bevezetett részallokáció célja, hogy megoldja a nem kellően megtöltött lemezpufferekből származó lemezterület-veszteség problémáját. A részallokációs funkció lehetővé teszi, hogy több fájl vége megosztozzon egy lemezblokkon. A részallokált blokkon belüli allokáció egysége az egyetlen szektor (512 bájt). Ez azt jelenti, hogy egyetlen 64 kilobájtos blokkban akár 128 fájlvég is tárolható. A részallokáció használatával a fájlonkénti maximális adatveszteség 511 bájt. Ez is csak akkor fordulhat elő, ha egy fájlban eggyel több bájt van, mint amennyi egy teljes 512 bájtos szektorba íródna. Így a részallokáció gyakorlatilag megszünteti a nagyobb lemezblokkok használatából származó veszteséget, ugyanakkor sokkal nagyobb lemezcsatorna-műveleteket tesz lehetővé.

Ami a teljesítményt illeti, a részallokáció javítja az írási műveletek teljesítményét azáltal, hogy több fájl végét egyetlen írási művelettel képes kiírni. Ezt a minimális javulást természetesen általában ellensúlyozza a részallokációs folyamat felügyeletének megnövelt számításigénye. A fő nyereség a lemezcsatorna optimalizálása és a 64 kilobájtos lemezblokkok használatából származó gyorsítás.

Mivel a képfeldolgozás, a multimédia és más hasonló feladatok terjedése miatt az adatfolyamok használata egyre gyakoribb, a 64 kilobájtos blokkméret használata rengeteg előnnyel jár. Azt ajánljuk, hogy mindenhol használjunk 64 kilobájtos lemezblokk-méretet a nagyobb hatékonyság érdekében, és használjuk ki az előreolvasási lehetőséget.

Igen fontos, hogy minden szoftverjavítást betöltsünk a részallokáció használatakor. A részallokációnak semmilyen beállítandó SET-paramétere nincs, minden automatikusan történik. Igen fontos azonban, hogy figyeljük a szabad területet a részallokációs problémák elkerülése érdekében. A Novell Engineering azt ajánlja, hogy tartsuk a kötet 10-20 százalékát szabadon a részallokációs problémák elkerülése érdekében.

A részallokáció szabad blokkokat használ funkciója ellátásához. Amikor kevés szabad blokk található, a részallokáció hajlamos átkapcsolni „aggresszív” módba, lezárni a kötetet és magas kihasználtságot okozni. Ha legalább 1000 szabad blokkot tartunk mindig a köteten, a legtöbb esetben elkerülhetjük ezt a problémát. Ha nincsen a köteten legalább 1000 szabad blokk, akkor futtassuk le a PURGE /ALL parancsot a kötet gyökérkönyvtárában. Ez felszabadít minden „felszabadítható” blokkot, és szabad blokkot csinál belőlük.

Disk Block Size (lemezblokk mérete)

Teljesítményvizsgálataink alapján 64 kilobájtos blokkméretet ajánlunk minden kötethez. A 64 kilobájtos allokációs egység használatával a NetWare hatékonyabban tudja kihasználni a lemezcsatornát, azáltal, hogy egyszerre képes olvasni és írni az adatokat. Ez a tömegtároló eszközökhöz való gyorsabb hozzáférést és a hálózati felhasználók felé mutatkozó jobb válaszidőket eredményez. Amennyiben RAID 5-lemezeket használunk, a blokkméretet állítsuk a RAID 5-lemezek csíkméretével megegyezőre.

Hotfix-blokkok

Töltsük be a SERVMAN-n, válasszuk ki a Storage Informationt (tárolóterület-információ) és jelöljük ki a szerveren lévő Netware-partíciókat. Ellenőrizzük, hogy nincs egy sem a Used Hotfix blocks (felhasznált Hotfix-blokkok) sorban. Alternatívaként betölthetjük a MONITOR-t, válasszuk ki a Disk Information (lemezinformáció) pontot, majd az eszközt, üssük le az <ENTER>-t és nyomjuk meg a <TAB> gombot. Itt látható az átirányított blokkok (Redirected Blocks) adatai. A Used Hotfix blocks és a Redirected Blocks egyaránt azt mutatják, hogy a szerver adott merevlemezén hibák vannak. Készüljünk fel e merevlemez mihamarabbi cseréjére.

A részallokáció és az egyes köteteken lévő szabad blokkok és terület mérete

Fontos, hogy legalább 1000 szabad blokkot (szabad blokkok) és a kötet területének legalább 10-20 százalékát szabadon hagyjuk azokon a köteteken, amelyeken be van kapcsolva a részallokáció. A részallokáció ezeket a blokkokat arra használja, hogy más blokkokat szabadítson fel. Ahhoz, hogy figyelmeztetést kapjunk a szabad blokkok számának csökkenésekor, állítsuk be a Volume Low Warning Threshold és a Volume Low Warning Reset Threshold értékeket 1024-re.

Magas kihasználtsági problémákhoz vezethet a lemezterület hiánya is. A részallokáció alapértelmezésben egy alacsony prioritású programszál. Ez azt jelenti, hogy normál körülmények között csak olyankor fut, amikor a processzor semmi dolga nincsen, és üresen járna. A részallokáció ezen állapotát „nem agresszív” módnak is hívjuk. Amikor azonban a szabad lemezterület lecsökken, 10 százalék alá, akkor a részallokáció „aggresszív” módba képes kapcsolni, normális prioritású programszállá válva, és lefoglalva a kötet szemaforját addig, amíg nem végzett és nem szabadított fel a lehető legtöbb területet. A kötet szemaforjának lezárása azonban más, szintén a kötethez fordulni próbáló folyamatokat feltarthat addig, amíg a szemafor újra szabadra nem áll. Nagy hálózatokban ez a csomagfogadó pufferek és a fájlszolgáltatás-folyamatok számának megnövekedésével járhat. Amikor a csomagfogadó pufferek száma eléri a maximális értéket, a szerver elkezdi megszakítani a kapcsolatokat, és a felhasználók nem lesznek képesek bejelentkezni. Miután a részallokáció befejezte a takarítást, elengedi a szemafort, és a sorban álló folyamatok mind kiszolgálódnak. A kihasználtsági érték újra leesik, és a szerver visszaáll normális üzemmódba.

A szabad blokkok hiánya nem jelenti feltétlenül a szabad lemezterület hiányát. Fájlok törlésekor azok először egy „törölt” állapotban tárolódnak tovább. Más szavakkal, a fájl továbbra is létezik, csak a felhasználó nem látja és nem jelenik meg a kötetstatisztikában felhasznált területként. A szabad blokkok száma az alábbi képlettel határozható meg:

Szabad blokkok = [Blokkok összesen – (A fájlok által használt blokkok + A törölt fájlok által lefoglalt blokkok)]

Így előfordulhat akár az is, hogy a lemezterület 50 százaléka szabad, ugyanakkor egyetlen szabad blokk sincs, mert törölt fájlok használják őket. Ha híján vagyunk a szabad blokkoknak, futtassuk le a PURGE /ALL parancsot a kötet gyökérkönyvtárában. Ez felszabadít minden „felszabadítható” blokkot, és szabad blokkot csinál belőlük. Ha nem akarjuk folyton ezt csinálni, akkor állítsuk be a P (PURGE) attribútumot azokon a könyvtárakon, ahol gyakran létrejönnek átmeneti állományok. A P attribútum beállításakor ne feledjük, hogy ez az attribútum nem öröklődik lefelé a fájlrendszerben. Hasonlóan, a szerverkonzolnál az IMMEDIATE PURGE OF DELETED FILES paraméter ON-ra állítása szintén megakadályozza, hogy a letörölhető fájlok elfoglalják az összes szabad blokkot.

Fájltömörítés

Létfontosságú, hogy betöltsük az összes szoftverjavítást a tömörítés használata esetén. A tömörítés a CPU-tól vesz el számítási kapacitást a fájlok tömörítésekor és kibontásakor. A tömörítés alapértelmezésű SET-paraméterei ezt számításba is veszik. A tömörítés úgy készült, hogy éjfél után induljon be, amikor a legtöbb szervernek minimális forgalma van csupán. A DAYS UNTOUCHED BEFORE COMPRESSION SET-paraméter pedig arra szolgál, hogy a sűrűn használt fájlok ne kerüljenek tömörítésre. A tömörítés alapértelmezésű SET-paramétereinek átállítása lényegesen befolyásolhatja a szerver teljesítményét.

A korlátozott lemezhozzáférésű felhasználóknak érdemes lehet IC-nek (immediate compress, azonnali tömörítés) megjelölni könyvtárukat a helytakarékosság érdekében. Az IC-nek megjelölt könyvtárak azonban hatással vannak a szerver teljesítményére. Normális esetben a tömörítés egy alacsony prioritású programszál, vagyis csak akkor tömörít a szerver fájlokat, ha éppen nincsen semmi egyéb dolga. Az IC flag beállítása után azonban a tömörítés normális prioritást kap, és nem várakozik üres időre.

A DELETED FILES COMPRESSION OPTION paramétert 2-re állítva a törölt fájlok azonnal tömörítődnek. Ez magas kihasználtságot eredményezhet, hiszen a processzor egy fájl törlése után azonnal nekilát a tömörítésének.

Hibakeresés:

Szüntessük meg a tömörítésből származó szűk keresztmetszeteket az ENABLE FILE COMPRESSION paraméter OFF-ra állításával. Ettől még a fájlok sorba fognak állni tömörítéshez, de a tényleges tömörítés nem zajlik le. Ugyanakkor az összetömörített fájlokat kicsomagolja a rendszer. Ez megszünteti a tömörítésből származó magas kihasználtsági problémákat.

Annak megállapításához, hogy milyen mértékben folyik a szerveren a tömörítés/kibontás, írjuk be az alábbiakat:

SET COMPRESS SCREEN = ON

Tanácsos a Days Untouched Before Compression paramétert 30 napra, a Minimum Compression Percentage Gain-t pedig 20 százalékra állítani.

Fájlkicsomagolás

Számítási kapacitást vesz igénybe a fájlok kicsomagolása is. Amennyiben egy olyan kötet, amelyiket a tömörítés be van kapcsolva, közel megtelik, előfordulhat, hogy a fájlok ugyan összetömörítődnek, ám soha nem kerülnek kiírásra, mert már nincsen elég hely a köteten a tömörített változatnak.

Ezt okozhatja az, ha a Minimum File Delete Wait Time paraméter túlságosan magas értékre van állítva, és így nem engedi a törölt fájlok által foglalt hely visszaszerzését a tömörített fájl kiírása érdekében. A kötet ezen állapotát általában a szerverkonzolon megjelenő Compressed files are not being committed (a tömörített fájlok nem íródnak ki) üzenet jelzi. Ez a hiba megoldható a Decompress Percent Disk Space Free To Allow Commit paraméter az aktuálisnál kisebb értékre állításával. Ugyanakkor ne feledjük, hogy a köteten elegendő helynek kell lennie a fájl tömörítetlen változatának is ahhoz, hogy a tömörített változat kiíródhasson.

A fájlok kibontása bár tényleg CPU-időt vesz igénybe, ez visszaadja a vezérlést a többi programszálnak és kiszolgálandó NCP-nek. Egy 60 megahertzes Pentium processzor másodpercenként átlagosan 1 megabájtot képes kicsomagolni.

Írás utáni visszaolvasásos ellenőrzés

Fontos módja az adatok védelmének az írás utáni visszaolvasásos ellenőrzés. Normális esetben semmiképpen ne kapcsoljuk ki. Ha azonban a lemezmeghajtók tükrözve vannak és megbízhatóak, érdemes lehet kikapcsolni az írás utáni visszaolvasásos ellenőrzést, ugyanis így majdnem duplájára gyorsulnak a lemezírási műveletek.

Figyelmeztetés:

Az írás utáni visszaolvasásos ellenőrzés kikapcsolása megnöveli a szerverek merevlemezén lévő adatok sérülésének esélyét. Csak akkor folyamodjunk hozzá, ha a lemezek tükrözve vannak, megbízhatóak, és pontosan tudjuk, milyen kockázatot vállalunk.

Garbage Collection (szemétgyűjtés)

A szemétgyűjtő folyamat lényegében az operációs rendszer memóriájának egyfajta töredezettség-mentesítője, amelyik folyamatosan fut.

A szemétgyűjtő folyamat célja, hogy az operációs rendszer visszaszerezze az egyszer már elhasznált memóriát más, új feladatok érdekében. A szemétgyűjtés kritikus fontosságú olyan esetekben, amikor az NLM-ek kis memóriaterületeket foglalnak le inicializációkor, majd nagyobbakat a műveletek befejezéséhez. Amennyiben a kisebb memória-adagok nem kerülnek vissza megfelelő módon a program inicializációja után, akkor a memória feltöredezik és használhatatlanná válik. Más szavakkal, a rendelkezésre álló memória kimerül.

Az operációs rendszerek a szemétgyűjtésért felelős belső rutinja sorbaszedi az NLM-ek listáiban lévő összes kis memóriaterületet, és nagyobb egységekké szervezi azokat. A nagyobb darabok ezek után a megfelelő listák elejére kerülnek. Ha a szemétgyűjtésért felelős rutin egy egész 4 kilobájtos lapot felszabadít, akkor az a memória visszakerül a cache-be. Ez a belső, háttérben futó rutin beállítható vagy megszakítható.

A szemétgyűjtés kikényszeríthető a felhasználó által is a MONITOR-on keresztül. Az NW4.11-ben a Memory Utilization (memória-kihasználtság) pontból kiválasztható bármelyik rendszermodul. A kiválasztás után kézzel, az <F3> gomb lenyomásával elvégezhető a szemétgyűjtés az adott modulra, <F5>-tel pedig az egész rendszerre vonatkozóan. NW5 esetében a Virtual Memory (virtuális memória), majd az Address Spaces (címterületek) pontok alatt szabadítható fel a megfelelő memória az <F4> gomb lenyomásával.

A memóriaszűkében lévő rendszerek felhasználói, illetve a saját NLM-jeiket optimalizáló fejlesztők számára érdemes lehet módosítani ezeket a paramétereket. Ha az NLM működése során nagy memóriadarabokat foglal le és ad vissza, akkor állítsuk a felszabadítások számát az alapértelmezésnél alacsonyabbra. Ha az NLM sok memóriafoglalást és -visszaadást hajt végre, akkor állítsuk a felszabadítások számát az alapértelmezésnél magasabbra. Ha az NLM ugyanazt a méretű memóriát egynél többször is lefoglalja és visszaadja, akkor a minimálisan felszabadítandó memória méretét állítsuk e memóriadarab méreténél nagyobbra.

Ne feledjük, hogy a szemétgyűjtés SET-paraméterei globálisak; más szavakkal az összes NLM szemétgyűjtését befolyásolják. &Eeacute;ppen ezért óvatosan állítsuk át az alapértelmezésű paramétereket. Egy NLM teljesítményének növelése egy másik lerontásáéval járhat. A Novell azt javasolja, ne változtassuk meg ezen paraméterek alapértelmezését, kivéve, ha egy NLM megköveteli.

Írási/olvasási hibák emulációja és érvénytelen mutatók

Amennyiben a NetWare olyan állapotot észlel, amelyik veszélyezteti a saját belső adatainak integritását (például egy funkcióhívás során átadott érvénytelen paraméter, vagy bizonyos hardverhibák), akkor hirtelen leállítja az aktív folyamatot és egy ún. abend-üzenetet ír ki a képernyőre. (Az abend kifejezés a számítógép abnormális leállásából – ABnormal END – származik.)

A NetWare abendjeinek elsődleges célja az operációs rendszer belső adatainak integritásvédelme. Ha például az operációs rendszer érvénytelen mutatókat talál a cache-pufferekben, és mégis tovább fut, az adatok előbb-utóbb megsérülnek és/vagy használhatatlanná válnak. Így egy NetWare-abend a rendszer és a felhasználók védelmének egyfajta módja az adatok sérüléséből származó megjósolhatatlan események ellen.

A NetWare 4 kihasználja az Intel szegmentációs és memórialapozási architektúráját. Minden egyes memórialap megjelölhető jelenlévőként, nem jelenlévőként, olvasásvédettként, írásvédettként, olvashatóként és írhatóként.

A szegmentációs és lapozási problémák okozta kivételek másképp kezelődnek, mint a szokásos megszakítások. Normális esetben a programszámláló (az EIP regiszter) tartalma elmentődik, amikor egy kivétel vagy egy megszakítás generálódik. Ugyanakkor a szegmentációból és lapozásból eredő kivételek lehetőségek nyújtanak az operációs rendszer számára, hogy helyrehozza az adott lapot: úgy, hogy visszaállítsa bizonyos processzorregiszterek tartalmát az értelmezés előtti állapotra, még mielőtt az utasítás megkezdődött volna. A NetWare 4 SET-paramétereken keresztül teszi lehetővé a laphiba-emuláció engedélyezését vagy letiltását, választást kínálva a program továbbfuttatása vagy az abenddel való leállás között.

NW 4.x szervereken, mielőtt nekilátnánk egy coredump elemzésének, illetve egy kihasználtsági vagy abend-probléma megoldásának, ki kell kapcsolnunk (OFF-ra kell állítanunk) az Allow Invalid Pointers (érvénytelen mutatók engedélyezése), a Read Fault Emulation (olvasásihiba-emuláció) valamint a Write Fault Emulation (írásihiba-emuláció) memóriaparamétereket.

Megszakítások lefoglalása és konfigurálása

A megszakításoknak prioritásaik vannak. A megszakítások sorban a legmagasabbtól a legalacsonyabb prioritásúig: 0, 1, 8, (2/9), 10, 11, 12, 13, 14, 15, 3, 4, 5, 6, 7. A 0-ás megszakítást a rendszeridőzítő, az 1-est pedig a Keyboard Data Ready (billentyűzet adat készen áll) jelzés használja.

Egy SFT III szerver esetében kézzel kell az MSL-kártyát a lehető legmagasabb megszakításra beállítani. Ezt kövesse a lemezvezérlő, majd a LAN-kártya, ebben a sorrendben.

Az ún. éltriggerelt megszakítások nem osztaható meg más eszközökkel, de a szinttriggerelt megszakítások igen. Szinttriggerelt megszakítások használatakor csak a pontosan ugyanolyan típusú eszközök – például 2 NE3200.LAN vagy 2 AHA2940 HBA eszköz – között osszuk meg a megszakítást. Nem azonos eszközök esetében sose tegyük ezt.

Set Reserved Buffers Below 16 Meg (a 16 megabájt alatti pufferek)

Ez a paraméter az olyan eszközmeghajtók számára lefoglalt fájlcache-pufferek számát határozza meg, amelyek nem képesek a 16 MB feletti memóriához hozzáférni. Memóriacímzési problémák származhatnak abból, ha a szerverben több, mint 16 MB memória van és a lemezvezérlő 16 vagy 24 bites DMA-t vagy busmaster DMA-t használ. &Eeacute;ppen ezért állítsuk a Reserved Buffers Below 16 Meg paramétert 200-ra a STARTUP.NCF-ben.

AppleTalk

Találkoztunk olyan esettel, amikor az ATXPR.NLM okozott magas kihasználtsági problémát. A 41MAC1.EXE már az ATXPR.NLM új változatát tartalmazza. A 41MAC1.EXE fájl megtalálható a LIB6 nevű NOVLIB-területetn. Amennyiben még ennél is újabbat találunk, használjuk azt. (Az NW410-hez az aktuális verzió a MACPT3D.EXE)

Nyomtatás

Egy szerverre sok nyomtatót kötve romolhat a hálózati teljesítmény. Ez természetesen attól is függ, milyen típusú nyomtatás zajlik: például a CAD/CAM-tervek nyomtatása sokkal több processzoridőt emészthet fel, mint a szöveges dokumentumoké. Amennyiben aggódunk, hogy ez kihasználtsági problémákat eredményez, célszerű úgy beállítani a nyomtatási eszközöket, hogy ők végezzék el a feldolgozást, ne a szerver. Ez ugyan lelassítja a tényleges nyomtatás sebességét, viszont nagy terhet levesz a szerverről.

Referenciaanyagok:

Novell Research AppNotes:
1993. május - NetWare 4.0 Performance Tuning and Optimization: Part 1
1993. június - NetWare 4.0 Performance Tuning and Optimization: Part 2
1993. október - NetWare 4.x Performance Tuning and Optimization: Part 3
1995. február - Resolving Critical Server Issues
1995. március - Server Memory
1995. április - MONITOR.NLM
1995. június - Abend Recovery Techniques for NetWare 3 and 4 Server November 1995 - Server Memory
1997. augusztus - IntranetWare Server Automated Abend Recovery
1997. március - Optimizing IntranetWare Server Memory TIDs:
TID14270 - NetWare 4.0 Memory Allocation - Part 1 of 2
TID14271 - NetWare 4.0 Memory Allocation - Part 2 of 2
TID1005436 - High Utilization and Suballocation
TID1005736 - Compression and High Utilization
TID1007561 - NetWare OS Patches
TID1005963 - Troubleshooting NetWare 4.1 High Utilization
TID1202046 - NetWare 3.x and 4.x Directory Entry Limits
TID2905856 - Additional Notes for High Utilization
TID2906943 - PC INTERRUPTS
TID2917538 - Suggestions for Troubleshooting Abends
TID2923372 - SFTIII configuration
TID2950154 - 8259 Interrupts and NetWare

Novell Press:
Novell's Guide to Resolving Critical Server Issues by Rich Jensen and Brad Dayley

Egyéb:

High Utilization, írta Rich Jardine, Product Support Engineer, NetWare OS Support, Novell Inc. (28 Sep 95)
Suballocation, írta Rich Jardine, Product Support Engineer, NetWare OS Support, Novell Inc. (1 Feb 96)
Compression, írta Kyle Unice, Novell Software Engineer (1 Feb 96)
FYI.P.12444 - What Does the Garbage Collection SET Parameter Do?
November 1993 - NetNotes

Letölthető fájlok:
HIGHUTL1.EXE - Troubleshooting High Utilization for NW4
TABND2A.EXE - Diagnostic programs / utilities to troubleshoot Abends
CONFG8B.EXE - CONFIG.NLM and CONFGNUT.NLM to collect server configuration
CFGRD6B.EXE - The Config Reader, Internet Edition! (version 2.67)