Valljuk be, az embernek ritkán van lehetősége ipari környezetben pontos kisérleteket végezni. Meg lehet tervezni a kísérletet virtuális gépen… de köztudott, hogy a méretkülönbségek miatt nem számíthatunk arra, hogy az éles környezetben minden ugyanúgy fog menni, mint a laborban.
Amikor nemrég átállítottuk egyik ügyfelünk levelezési rendszerét Exchange2007-re, volt egy olyan időszak, amikor enyém volt a pálya. Rendes, ipari erősségű szerver dübörgött a gépteremben, 1 teszt user postafiókja volt csak rajta. Remek lehetőségem nyílt arra, hogy kimonitorozzam, 1 átlagos felhasználó mekkora terhelést okoz egy valós szervernek. Vannak rá ügyes perfmon counterek, ezek közül ez érdekelt engem konkrétan: ‘RPC operations per second per user’. (Természetesen nem a perfmon-ból vizsgálódtam, vannak az EMC-ben erre a célra felingerelt varázslók bőségesen a Tools menüpont alatt.) Nagyjából annyit illik erről az értékről tudni, hogy ha az értéke 0,25 fölé megy, az már gáz.
Ekkortájt hülyült meg a laptopom, időnként be-bevillantott egy-egy kékhalált. Mivel az Outlook-om cached módban ment, ilyenkor nyilván jönnie kellett egy ost adatbázis reparációnak is az újraindítás után. Nos, ezt is lemonitoroztam… és kikerekedett rendesen a szám: a mutató 0.41-re lendült ki.
Próbáljuk meg értelmezni:
- Nyilván ahhoz, hogy a szerveren tárolt adatokat össze tudja vetni az ost-ben tárolt adatokkal, rengeteg információt kellett MAPI-n keresztül lerántania a szerverről. Márpedig a MAPI az RPC.
- Valószínűleg az “extrém nagy” terhelés meg se kottyant a szervernek, hiszen egyedüli felhasználó voltam, azaz a “per second per user” érték lehetett nagy, de az abszolút terhelés bőven normálison belül maradt.
Ennek ellenére mégis érdemes elgondolkodni a számon. Sok felhasználó esetén nem tudhatjuk, ki milyen kérésekel bombázza a szervert: az ost reparálás mellett bejátszik a desktop search is, amennyiben beállítottuk, hogy az legyen a keresőnk az Outlook alatt, de ugyanígy bejátszik, ha alternatív keresőt – pl. lookout – használunk, bejátszhatnak archiváló szoftverek, bejátszhat egy CRM… bejátszhat minden, ami a postafiókot piszkálja. Ja, és bejátszhat a felhasználó is, pusztán azzal, hogy használja az Outlook-ját: levelez, megbeszélést szervez, kontaktok között keres.
A kérdés: mi történik, ha túlterheljük a szervert? Ha túl sok RPC kérést kap?
Alapvetően három viselkedési mód képzelhető el:
- A szerver megpróbálja kiszolgálni az ígényeket, csak gyűjti, gyűjti… aztán halk sóhajtással összeszakad. A levelezés megáll.
- A szerver, amikor észreveszi, hogy baj van, nem bír többet, nemes egyszerűséggel nem foglalkozik a bejövő kérésekkel, amíg nem lesz rájuk erőforrása. Ekkor néhány kliens fogja úgy érezni, hogy a szerver nem működik – dea többiek makacsul nyomulnak.
- A szerver, amikor észreveszi, hogy baj van, akkor visszaszól. Egész pontosan azt fogja mondani a nagy terhelést okozó klienseknek, hogy lassítsatok be, nem bírom feldolgozni a kéréseiteket.
Nyilván az első mentalitás halálos. Nem szeretjük. A másodikat se túlzottan, de már megszoktuk: az Exchange szerver eddig ugyanis így működött. Eddig. Az Exchange 2007 SP1 viszont átváltott a harmadik módszerre. Ezt hívják úgy, hogy client throttling, azaz kliens fojtogatás.
Nézzük a részleteket. A szerver kezd lemerülni. Ekkor gyorsan beazonosítja, kik azok a kliensek, akik a legnagyobb terheléseket okozzák, majd küld nekik egy-egy pofabe üzenetet. Ezt úgy hívják, hogy back-off. Aztán mit mond erre a kliens? A nevelésétől függ.
- Az Outlook 2007 kliensek úgynevezett ropBackoff üzenetet kapnak. Ebben benne van az az információ, hogy mennyi ideig ne próbálkozzanak új RPC kéréssel. De mi van, ha a kliens csak azért is próbálkozik? A szerver türelmesen küld neki egy újabb ropBackoff üzenetet, módosított időlimittel.
- A korábbi kliensek nem értenék ezt az üzenetet, ezért nem is ezt kapják. Helyette a szerver a képükbe tol egy RPC_S_SERVER_TOO_BUSY üzenetet. Ilyenkor a kliens beállításától függ a várakozási idő. Alapban 1 másodperc. Aztán ha túl sűrűn kapja vissza ezt az üzenetet, akkor bontja a kapcsolatot és kiírja, hogy az RPC szerver nem elérhető.
Aki komolyabban is kíváncsi a jelenségre, perfmonból meg lehet tekinteni. A countert úgy hívják, hogy RPC Client Backoff/sec. Vigyázat, más nagyságrendeket fogunk látni, attól függően, hogy milyen klienseink vannak: ropBackoff üzenetek sokkal sűrűbben keletkeznek, pont a finomabb szabályozás érdekében. A normál értékek: Outlook 2007: 50/kliens, korábbi Outlook kliensek: 1/kliens. Azaz a korábbi kliensek csak 1 pofont kapnak, de az jó nagy.
Mi van még? Igen, lehet állítani azt a küszöbértéket, amikortól a szerver úgy érzi, hogy baj van. Természetesen registry varázslással. A magam részéről úgy vélem, átlagos környezetben erre nincs túl nagy szükség. Bízzunk a szerverben, csak tudja, mikor fárad el. Amennyiben valaki mégis állítgatni akarja, akkor ebben a cikkben megtalálja a szükséges matekozást.
Recent Comments