2012. október 8., hétfő

DynaTrace - A feltárt szerver oldali hibák 1.

A stabilizációs projekt során közel 500 hibát sikerült beazonosítanunk és megoldanunk, melyek döntő többsége valamilyen kódolási vagy konfigurációs problémára volt visszavezethető. A következő néhány bejegyzésemben ezekből emelnék ki néhány fontosabbat és írnék a megoldásukról is!

Nem optimális JVM beállítások

Az éles banki környezetben több mint 10 WebSphere klaszter volt kialakítva. A WAS szerverekhez kapcsolódó performancia problémák nyomozásakor találtunk környezetenkénti konfigurációs eltéréseket (melyek megelőzéséről egy későbbi cikkemben fogok írni) valamint nem optimális és hiányzó beállításokat melyekből most csak egyet emelnék ki, mégpedig a JVM Garbage Collector beállításait.

Amikor egy alkalmazás szerveren tranzakcionális jellegű web-alkalmazásokat futtatunk (melyeknél sok a rövid életű objektum), akkor IBM JVM esetén a gencon lesz a nyerő Garbage Collector stratégia! Ennek ellenére a szerverek többségénél nem volt megadva gc policy (alapértelmezett az optthruput) vagy egy másik gc policy volt definiálva, ahol pedig a gencon volt beállítva a nursery terület mérete túl alacsonynak bizonyult, feltehetően nem volt finomhangolva.

Habár a JVM GC tunning a VisualVM eszközzel is megoldható lett volna,  nekünk pont jól jött hogy a DynaTrace is támogatja a JVM monitorozását. A gc suspension time és a heap memória kihasználtság monitorozásához így összedobtunk egy DynaTrace-es dashboard-ot, az optimalizálás során pedig közel 90%-os GC suspension time csökkenést sikerült elérni, ami várakozási időben elég komoly javulást jelentett. (lásd az alábbi ábrákat)


Hiányzó IceFaces konfigurációs paraméterek

A DynaTrace beépített Exceptions nézetét használtuk fel, hogy a keretrendszeri és az alkalmazásokhoz tartozó kivételeket láthatóvá tegyük. Esetünkben a top 20-as listában jópár IceFaces-es kivétel keletkezett, melyek hiányzó web.xml konfigurációs paraméterekre voltak visszavezethetők!


Persze felmerülhet a kérdés, hogy milyen költséges lehet egy kivétel feldobása? Általában elhanyagolható, azonban a fenti esetben ez a kb. 10.000 IceFaces-es kivétel mindössze 10 perc alatt gyűlt össze, így egyértelműen javítani kellett! Amire érdemes odafigyelni, hogy nagy számú kivétel esetén a catch ágban elhelyezett kompenzációs logika valamint a több rétegen keresztül gyűjtögetett stack trace-ek kinaplózása okozhat még jelentősebb performancia problémát!

A folytatás hamarosan következik...



Nincsenek megjegyzések:

Megjegyzés küldése