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)
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
Megjegyzés: Megjegyzéseket csak a blog tagjai írhatnak a blogba.