Ny\u00e1ron k\u00e9t \u00e9rdekes \u00e9s neh\u00e9z esetem is volt \u00fcgyfelekn\u00e9l, mindkett\u0151h\u00f6z memory dumpokat is kellett elemezni WinDbg-gal. Elmes\u00e9lem az els\u0151t.<\/p>\n
Ebben teljesen kisz\u00e1m\u00edthatatlan m\u00f3don felment a webszerver cpu-ja 100%-ra, \u00e9s nagyon belassult a kiszolg\u00e1l\u00e1s raja. A procit a w3wp.exe vitte el, azaz nem valami meg\u0151r\u00fclt v\u00edrusirt\u00f3 vagy egy\u00e9b m\u00e1s \u00e1rtalmas processz. Sajnos az elej\u00e9n ez a t\u00e9ny, hogy nagy cpuval j\u00e1r egy\u00fctt a belassul\u00e1s nem volt m\u00e9g egy\u00e9rtelm\u0171, \u00edgy nem ebbe az ir\u00e1nyba kezd\u0151d\u00f6tt a nyomoz\u00e1s.<\/p>\n
DynaTrace agent fel volt telep\u00edtve a szerverekre (okos kis cucc), ami alapj\u00e1n l\u00e1tszottak a k\u00e9r\u00e9sekhez tartoz\u00f3 stack trace-ek \u00e9s .NET statisztik\u00e1k is. Az alapj\u00e1n vagy a webapp -> web service h\u00edv\u00e1sok voltak lass\u00faak, vagy a GC vitt el t\u00fal sok id\u0151t. A h\u00e1l\u00f3zati \u00e9s szerviz probl\u00e9m\u00e1t egy id\u0151 ut\u00e1n ki lehetett z\u00e1rni, mivel a szerviz oldalon p\u00e1r ms alatt lefutottak a h\u00edv\u00e1sok. A .NET h\u00e1l\u00f3zati traceinget is bekapcsoltuk, hogy webapp oldalr\u00f3l milyen id\u0151kkel mennek a h\u00edv\u00e1sok, de ebben minden inf\u00f3 benne volt, csak a timestampek nem. Nesze semmi fogd meg j\u00f3l.<\/p>\n
A GC \u00fcgyre nem tudtam semmit mondani. Eg\u00e9szen pontosan a DynaTrace Suspensi\u00f6nt mutatott, azaz valamire v\u00e1rakoztak a sz\u00e1lak. A doksija szerint ez \u00e1ltal\u00e1ban GC-re v\u00e1rakoz\u00e1st jelent. \u00c1ltal\u00e1ban. A .NET GC perfmon counterek ezt nem er\u0151s\u00edtett\u00e9k meg. A h\u00e1l\u00f3zatra \u00e9s egy\u00e9b IO-ra v\u00e1rakoz\u00e1s k\u00fcl\u00f6n t\u00e9tel volt a list\u00e1n, \u00edgy a suspension oka rejt\u00e9ly maradt. A memory dumpok nem seg\u00edtettek, mivel mind olyankor k\u00e9sz\u00fclt, amikor m\u00e1r rendben volt a g\u00e9p, apppol recycling miatt.<\/p>\n
Szerencs\u00e9re a tesztel\u0151 koll\u00e9ga nagyon lelkesen seg\u00edtkezett, \u00e9s a tesztjeivel siker\u00fclt reproduk\u00e1lni a probl\u00e9m\u00e1t. Hogy pontosabban l\u00e1ssuk, mi t\u00f6rt\u00e9nik, felraktunk egy g\u00e9pet a staging szerverre, \u00edgy \u00fagy tudtunk m\u00e9rni profilerrel, mi t\u00f6rt\u00e9nik a worker processzben.<\/p>\n
Amikor v\u00e9gre siker\u00fclt reproduk\u00e1lni a hib\u00e1t, v\u00e9gre saj\u00e1t szememmel l\u00e1ttam, hogy a cpuk ki\u00fclnek 100%-ra, \u00e9s odaragadnak. Annyira le volt terhelve a g\u00e9p, hogy nem is lehetett haszn\u00e1lni a profilert, task managerben el kellett vennem a processor affinity-n kereszt\u00fcl p\u00e1r procit a w3wpt\u0151l, hogy a visual studio egy\u00e1ltal\u00e1n meg tudjon nyekkenni.<\/p>\n
A profiler m\u00e1r k\u00f6zelebb vitt a probl\u00e9m\u00e1hoz, az id\u0151 z\u00f6me a Dictionary<\/a>.FindEntry met\u00f3dus\u00e1ban ment el.
\nEzt h\u00edvja a TryGetValue, a ContainsKey \u00e9s az Indexer, ez a f\u0151 keres\u0151 r\u00e9sze. Mivel a Dictionary arr\u00f3l h\u00edres, hogy igen gyors, arra gondoltam csak az\u00e9rt megy el itt annyi id\u0151, mert v\u00e9gtelen cilusba ker\u00fcl a Dictionaryt h\u00edv\u00f3 k\u00f3d, valamilyen k\u00f3dszervez\u00e9si hiba miatt. Ez\u00e9rt raktunk a k\u00f3dba egy sz\u00e1ml\u00e1l\u00f3t, h\u00e1nyszor h\u00edvj\u00e1k meg a Dictionary-t piszk\u00e1l\u00f3 met\u00f3dust, \u00e9s kilogoltuk a % 1000000-dik h\u00edv\u00e1st. V\u00e1rtunk, v\u00e1rtunk, de nem keletkezett log.<\/p>\n