ValószÃnűleg több sorstársamnak is keserÃtette már meg az életét a fenti üzenet. Az Outlook kliens monoton homokórázik, a felhasználó csak ül, és a rendszergazdával karöltve szelÃden bámulják a monitort.
Ashley Webb leÃrt egy történetet, ahol igen trükkösen kerÃtették be ezt a vadat.
Megjegyzés: a sztori - sajnos - nem egy univerzális módszer a probléma megszüntetésére. Csak érdekes megoldás egy szituációra.
Arról volt tehát szó, hogy a klienseknél teljesen sztochasztikusan bejött ez a hiba, miközben az Exchange szerver összes lényeges teljesÃtménymutatója teljesen rendben volt. (InnentÅ‘l speciális a történet; a jelenséget ugyanis általában valamilyen szerveroldali/hálózati szűk keresztmetszet okozza.)
Webb szerette volna, ha a homokórázás alatt le tudja menteni az Information Store és a System Attendant által használt memóriatartalmakat (ADPlus.vbs), de ennek igen komoly akadálya volt a véletlenszerű előfordulás. Egész nap csak nem ülhet ott egy biorobot a szerver előtt, a telefonra koncentrálva…
Viszont rájöttek, hogy van egy mutató (Average RPC Latency), mely felugrik, ha bekövetkezik a hiba. Ez jó, mert a permormance monitorban rátettek egy alertet erre a mutatóra, mely egy küszöb átlépésekor automatikusan elindÃtott egy programot - az ADPlus.vbs-t.
79 példányban. Ugyanis a dump elég hosszú ideig tartott, közben pedig az érték többször is leesett, majd visszaugrott. Itt egy garázsszagú buhera következett, összedobtak egy parancsfájlt, ez úgy indult, hogy megvizsgálta egy bizonyos txt fájl létezését: ha nem létezett, akkor létrehozta, majd futott tovább; ha létezett, akkor a szkript megállt.
És ennyi. Megszerezték a kÃvánatos memóriatartalmat.
A módszernek volt egy apró mellékhatása: a dump igen erÅ‘forrásigényes művelet, rendesen leterhelte az Exchange szervert. AmÃg futott, addig nem is volt ideje kiszolgálni a klienseket.
Mit csinált helyette? Úgy van, kiszórta nekik is a cÃmben szereplÅ‘ üzenetet.:-)



Tags:
Leave a Reply