Hiljuti kirjutasin postituse Sharepointi IIS -i application pool -i konfigureerimisest. Seal kirjeldasin konfiguratsiooni, mida vaikimisi kasutan Sharepointi juures (ja olen selle õppinud ühelt Technical Evangelistilt Sharepointi teemal, kes sisemiselt sharepointiga tegeleb). Samas iga IIS -i rakenduse puhul tuleb application pool seadistada vastavalt serverile, rakenduse nõuetele ja rakenduse ressurside kasutamisele (vajadustele).
IIS -i application pool -i seadete aknas on ka rakenduse tööprotsessi mälu vabastamise konfigureerimise võimalus. Minu kirjutatud postituses seadsin limiidi nii füüsilisele kui ka virtuaalsele mälule ja ma igati soovitan need limiidid määrata. Küsimus on ainult suuruses ja ajastuses ning sellest ma ka täna räägin. Et te ei peaks oma IIS -i kohe lahti tegema ning õiget akent otsima hakkama, siis all on pilt, millest juttu tuleb.
Kui te seate niisugused limiidid, tuleb endale teadvustada, et kui virtuaalne või füüsiline mälu maht kasvab antud limiidini, siis tööprotsess tapetakse ära ning järgmine request saidi poole tähendab saidi kompileerimist ja cachimist ning ka kõik alamsaitidele minemised on esmakordsed ning protsess sama. Igatahes on teil esimese laadimise performance hit. Mis on täiesti loogiline.
Nüüd teil võib tekkida antud limiitide seadmisest jõudlusprobleem - olukord, kus tööprotsessi hakatakse tapma liiga tihti ja just selle tulemusena, et limiidid on liiga väiksed seatud. Kusjuures jõudlust hinnates, ei pruugi esimese mõttena just IIS -i applicationi pooli peale mõelda - üldse igasuguse jõudlusprobleemi leidmine ja lahendamine on tihti peale keerukas ja aeganõudev protsess.
Kuidas tuvastada jõudlusprobleemi seoses tööprotsessi tapmise/suremisega (recycle).
Üks lihtne viis on avada Task Manager ning jälgida, mis tööprotsess konkrteetse saidi juures käima läheb ning jälgida, kas käies lehel ringi tööprotsess sureb ja kui tihti. Veidi tülikas tegevus.
Järgmine viis on seadistada IIS jälgima kindla application pool -i tööprotsesside recycle sündmusi. Selle seadistamine on väga lihtne ning peale seadistuse, tuleb vaid oodata kirjeid System EventLog -i. Kusjuures teated on informatiivsed! (et te ei otsiks warning või error teateid). See et tööprotsess recycle -takse on normaalne osa application pooli tääprotsesside elutsükklist.
Õpetus antud sündmuste jälgimise seadistamiseks leiate siit.
Lisaks sellele on võimalik detailselt jälgida application pool -i tööprotsessi kasutades IIS Diagnostics Toolkit -i (jõudluse teemal lisainfot). Antud toolkit sisaldab erinevaid vahendeid IIS -i logide, rakenduse tööprotsesside jne info kogumuseks ja analüüsimiseks. Näiteks IIS Debug Diagnostics tool -ga on võimalik kindlat protsessi jälgida ning hiljem vaadata, kuidas mäluga ümber käidi (jm jõudlusandmeid). IIS log parser võimaldab analüüsida IIS -i logisid.
Nüüd, minul on konkreetne kogemus virtuaalse mälu limiidi täitumisega, füüsilist mälu kasutust on kuidagi kergem hinnata ja sellega on probleeme harvem. Mulle tundus selle projekti juures, et füüsilisele mälule vastavalt oli alati kaks korda rohkem virtuaalset mälu kasutuses. Nii, et kui te seate piirangud samas nii füüsilisele kui ka virtuaalsele ja see limiit ei ole väga suur, siis võite arvata, et varsti hakkab tööprotsess regulaarselt otsi andma.
Mis asi see virtuaalne mälu on, selle kohta lugege siit. Antud lehel on välja toodud ka OS -i piirangud virtuaalsele mälule. Igatahes Win2k3 -s Task Manageris olev veerg VM Size, ei näita seda numbrit. Administrative tools all on olemas viide niisugusele rakendusele nagu Performance, mis võimaldab erinevaid süsteemi jõudlus lugejaid (performance counter) vaadata ja selle abil näete ka oma tööprotsessi virtuaalse mälu toimimist (lisage perf. counter Process alt õigele w3wp protsessile). Teine variant on panna IIS Debug Diagnostics tool jälgima protsessi ning saate ka teada virtuaalse kasutuses oleva mälu suuruse lisaks muule infole. Jälgige ja leidke omale sobiv limiit virtuaalsele mälule.
Minu soovitus hetke kogemuse põhjal - virtuaalse mälu limiit peaks olema ~1.5-2x füüsiline mälu.