Soci (Soczó Zsolt) szakmai blogja

2017.09.22.

Debugolás Visual Studio 2017-ben

Filed under: .NET,C#,Debugging,Szakmai élet,Visual Studio — Soczó Zsolt @ 16:02

.NET Core és VS 2017 alatt van egy újfajta debug symbol kezelési módszer, a source link.
Itt egy egyszerű leírás, hogyan kell használni.

Tök szépen lehet a core kódokat így debugolni, csak szokás szerint a lokális változók nem látszanak.

2017.09.04.

IIS lassulás probléma – help needed

Filed under: Szakmai élet — Soczó Zsolt @ 20:44

Kivételesen nem megoldást írok le, hanem kérdést teszek fel.

Egyik ügyfelemnél vagy egy eset, amit egyelőre nem sikerült visszafejteni. Adott 3 IIS publikus web láb NLBS-sel összenyalábolva, és 3 belső IIS alatt futó WS szintén NLBS mögött, ezeket hívják a külső webappok. A Windowsok VmWare alatt vannak virtualizálva.

A hiba az, hogy random időpontban belassulnak a webszerverek webszervizek irányába mutató hívásai. Normál esetben egy gyors ws metódus hívása 2-5ms, amikor beáll ez az állapotváltás a webszerver worker process belsejében, akkor felmegy kb. 200 ms-re.

Azért írok állapotváltást, mert nem azért lassulnak be a dolgok, mert nap közben nagyobb a terhelés, hanem egyszer csak “elborul” a webapp, és belassul. Dynatrace alapján a ws hívások mélyén a recv windows hívás válaszol lassan. Ilyenkor a ws iis logjában is lassú a hívás, vélhetően mert a webapp mint kliens lassan viszi el az adatot.
Hamarosan lesz DotTrace lenyomat és FREB log is, illetve System.NET trace is (csak ez nagyon sok adatot termel).

IIS App reset megoldja a problémát egy ideig. Ha egy app beteg, akkor egy console appból ugyanaz a ws hívás ugyanezen a gépről a wsek felé gyors, tehát nem valószínű, hogy a wsek lassulnak be.

Nehézkes megfogni az estet, mert pl. egy config módosítás a trace-ek kedvéért azonnal appol resetet csinál, így elillan a hiba, aztán lehet megint egy napot várni rá.

A .NET perf counterek nem mutatnak kiugró értékeket, minden normálisnak tűnik. A web processben kb. 500 szál fut 1-3 kérés/sec esetén, ez mondjuk kicsit soknak tűnik, de a procmon nem mutatta meg a managed stacket (debug symbolokkal se), majd csak dottrace-ből látszik, mit csinálnak. A procik 10%-ig vannak kiterhelve. A diszk terhelés minimális, paging nincs, van 0.5G szabad memória, más proceszek nem eszik el az erőforrásokat. A resource monitorban a wsek irányába futó kérések jelentős része 200ms körüli latency-t mutat, ez egybevág más megfigyelésekkel.

Látott már ilyet valaki? Mit lehetne még mérni, amire nem gondoltam?

2017.09.02.

.NET optimalizálási praktikák

Filed under: .NET,Optimalizálás,Szakmai élet — Soczó Zsolt @ 10:25

Akik olyanok mint én, hogy az utolsó órajelet is meg akarják sprórolni, azoknak érdekes .NET optimalizálási cikk.

(Nitpickerek kedvéért: nyilván akinek minden ns számít, az nem .NET-ben programoz.)

Powered by WordPress