How can I tell what caused IIS memory to spike?
My website memory consumption shows a memory spike and I'd like to know the best way to go about figuring out what the spike was from. My best guess it to look at the time frame and look at the purepath with the longest duration. What is a better way? I should be able to right click on that point in the graph and go to something directly which would tell me exactly what it was?
thanks
Assuming you can log in to the support site there is a document entitled:
https://apmcommunity.compuware.com/community/display/DOCDT42/Analyzing+a+slow+transaction (Analyzing a slow transaction) - would this be a good place to start?
Thanks. That's what I ended up doing. It happened to be a slow running transaction but it that was by coincidence. I was hoping something built into dynatrace would just tell me more easily than me digging thru the data.
Steven's link is a good start.
Additionally I would recommend reading up on our Enterprise Performance Book - it is focused on Java - but - same applies to .NET as well: https://book.dynatrace.com/content/memory/how-garbage-collection-works.aspx
In order to analyze memory leaks - or spikes - I also recommend looking into our Memory Diagnostics capabilities: Memory Diagnostics
If you haven't captured any memory dumps while this spike happend and if the spike doesnt occur anymore you are probably really good with looking at the PurePaths that ran in that particular timeframe. Maybe not only focus on those that ran long - but look at them in general. Even a short running can allocate a lot of memory
Andi
Thanks for the information, I'll take a look. I was able to determine the problem after some digging but I thought dynatrace would just be able to tell me that information directly.
I dont have a memory dump as I observed it after the fact. Had I taken a dynatrace snapshot, would I be able to take a memory dump from that?
If you want to analyze which objects are actually causing these memory spikes and if you want to know which code creates these objects then you need to use our memory diagnostics feature including the memory dumps
However - what you can also do without memory dumps are things like
a) analyze slow transactions in that timerange
b) look at GC Activity and correlate that to the transaction that run at the same time when GC went up as some of these transaction are probably causing the problem
Andi
Now you have made me curious - on our 4.2 dyanTrace server, in a directory entitled d:\dynatrace\sessions\stored\ECS we have lots and lots of what look like memory dumps – are these normal session files are do we need to investigate further?
20120625122645_0.session
20120625163859_0.session
20120626145137_0.sampling
20120626145219_0.sampling
20120626145244_0.sampling
20120626145901_0.threaddump
20120626150141_0.memdump
20120626150211_0.memdump
20120626150241_0.memdump
20120626150834_0.memdump
20120627080014_0.session
20120628090125_0.threaddump
20120628101710_0.session
20120629095301_0.memdump
20120629095501_0.threaddump
20120629100301_0.memdump
20120629100502_0.memdump
20120629100515_0.memdump
20120629100529_0.memdump
20120629100543_0.memdump
20120629100600_0.memdump
20120629100620_0.memdump
20120629100630_0.memdump
20120629101301_0.memdump
20120629102301_0.memdump
20120629103301_0.memdump
20120629104301_0.memdump
20120629110502_0.memdump
20120629110520_0.memdump
20120629110529_0.memdump
20120629110543_0.memdump
20120629110558_0.memdump
20120629110607_0.memdump
20120629110622_0.memdump
20120629115730_0.session
20120629120502_0.memdump
20120629120515_0.memdump
20120629120529_0.memdump
20120629120543_0.memdump
20120629120600_0.memdump
20120629120611_0.memdump
20120629120625_0.memdump
20120629130502_0.memdump
20120629130520_0.memdump
20120629130537_0.memdump
20120629130555_0.memdump
20120629130617_0.memdump
20120629130625_0.memdump
20120629130642_0.memdump
20120629140502_0.memdump
20120629140515_0.memdump
20120629140529_0.memdump
20120629140543_0.memdump
20120629140555_0.memdump
20120629140607_0.memdump
20120629140622_0.memdump
20120629150502_0.memdump
20120629150515_0.memdump
20120629150529_0.memdump
20120629150543_0.memdump
20120629150603_0.memdump
20120629150615_0.memdump
20120629150622_0.memdump
20120702102202_0.session
20120703131822_0.session
20120703153440_0.session
20120709101452_0.session
20120709103954_0.session
20120725131336_0.session
20120725153402_0.session
20120726071107_0.session
20120726142942_0.session
20120801100134_0.session
20120801150747_0.memdump
20120807140021_0.session
20120808173944_0.session
20120811042028_0.session
20120814191622_0.session
20120925112541_0.session
20120925114549_0.session
20120925124801_0.session
20120927113556_0.session
20121001085024_0.session
20121001111908_0.session
20121002134241_0.session
20121002135414_0.session
20121002160633_0.session
20121015124058_0.session
20121018182602_0.session
20121022163233_0.session
20121023075517_0.session
20121024094245_0.session
20121101122526_0.session
20121101124657_0.session
20121103173118_0.session
20121108110032_0.session
20121116182443_0.session
There is no reference to these in the 4.2 documentation - should there be?
Some of these sessions are Memory and CPU Sampling Sessions. Just open your Session Browser Dashlet and you will be able to analyze the content of these sessions.
