IIS 7 and Above
IIS Worker Process - Application Pool Memory Issues
Last post Nov 20, 2019 06:18 PM by carehart
Nov 19, 2019 08:31 PM|Ebert|LINK
Nov 19, 2019 09:12 PM|lextm|LINK
I have been doing some simple troubleshooting for memory leaks. I have change my code to just display "Test". When I hit refresh the IIS Worker Process memory usage increases and will keep increasing after every refresh even when using simple code.
That's not valid "troubleshooting". GC based programs always work that way.
finally the website errors out.
What's the error? OutOfMemoryException? If you don't make that clear, no answer can be made.
Typical ASP.NET troubleshooting requires careful analysis, https://support.microsoft.com/en-ca/help/893660/quick-things-to-check-when-you-experience-high-memory-levels-in-asp-ne If
you have no experience in such, I suggest you open a support case via
http://support.microsoft.com to involve Microsoft support team.
Nov 20, 2019 02:51 AM|Yuk Ding|LINK
Is the high memory keep 95% memory usage all the time and never being released? If the memory usage goes down after a shortperiod of time, then we would not consider it as high memory issue.
If the Memory useage never goes down, then it is recommended to deep analyze the dump file with WINDBG. You could install it via WIN 10 SDK.
First of all, we need to figure out the object consume high memory and exception. You also need to monitor the managed stack trace.
If you are not expert in analyzing dump file, you could just open a support ticket to microsoft and they will help you analyze dump file and help you figure the root cause out.
If the reply is helpful, it is appreciated if you could mark it as answer.
Nov 20, 2019 11:14 AM|Rovastar|LINK
Nov 20, 2019 06:18 PM|carehart|LINK
While I don't disagree with the comments made so far, I will offer a couple of different thoughts.
First, yes, it is possible to set the app pools to recycle on reaching a given memory amount. As for "which" of those two values to use, I would recommend you look at the "worker processes" monitor feature, offered at the server level (not web site level)
within IIS. When you open that, it shows what app pool instances, if any, are running. And it shows a column for each of private and virtual bytes, which you can use to determine the current value, and at what amount you may want the app pool to recycle.
That said, do beware that simply telling the app pool to recycle this way is not so much a solution but a workaround. As others are saying, if memory rises and doesn't fall, something is using that memory.
And while the diagnostic approaches so far are indeed the classic ones, I will offer a guess. Since by default, asp.net sessions are stored "in process" in the application pool instance memory. If you may have a very high rate of traffic from spiders and
bots, they could be creating lots of sessions with perhaps lots of objects (depending on what your app may put into the session scope). Whenever a request comes in without any cookies (tying them to any previous request from the same client), then a new session
is created. And spiders and bots (and hackers and those trying to abuse your server) may send tens of thousands of requests to your server, day after day, each creating new sessions that then may be set to last for hours.
I realize that last problem may not be YOUR problem, but I have found it over the years to be the cause of SOME people having memory run up. I will point out that with Windows Performance Monitor, you could look at counters for ASP.NET that would track counts
of current and total sessions, as well as counts of requests total and per second, all of which may give a sense of whether this may be a problem at all for you. Do note that perfmon will let you get those counts per app pool instance, or total across all,
I will not detail how to go about using perfmon, as one can find that pretty readily via web searching.
Hope something above may help, you or future readers.