IIS Worker Process - Application Pool Memory IssuesRSS

4 replies

Last post Nov 20, 2019 06:18 PM by carehart

  • IIS Worker Process - Application Pool Memory Issues

    Nov 19, 2019 08:31 PM|Ebert|LINK

    I have an ASP.NET MVC internal website. I have seen the IIS Worker Process memory grow and grow until finally the website errors out. On the current production Intranet Server I am currently restarting the IIS service nightly, but at mid afternoon the memory % on the server is over 95%. 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. Would it help to set some memory caps in the Application pool in IIS and if so should I put max Virtual and or Private memory ? What else should I be looking at? Thanks, EB
  • Re: IIS Worker Process - Application Pool Memory Issues

    Nov 19, 2019 09:12 PM|lextm|LINK

    Ebert

    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.

    Ebert

    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.

    Lex Li
    https://lextudio.com
    ---------------------------
    This posting is provided "AS IS" with no warranties, and confers no rights.
  • Re: IIS Worker Process - Application Pool Memory Issues

    Nov 20, 2019 02:51 AM|Yuk Ding|LINK

    Hi Ebert,

    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.

    https://blogs.msdn.microsoft.com/benjaminperkins/2016/11/07/lab-21-debugging-a-w3wp-process-with-high-memory-consumption/

    https://blogs.msdn.microsoft.com/benjaminperkins/2018/04/13/memory-consumption-issue-with-windbg-address-summary/

    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.

    https://support.microsoft.com/en-us

    If the reply is helpful, it is appreciated if you could mark it as answer.

    Best Regards,

    Jokies Ding

    Yuk Ding

    MSDN Community Support
    Please remember to "Mark as Answer" the responses that resolved your issue.
  • Rovastar Rovastar

    5446 Posts

    MVP

    Moderator

    Re: IIS Worker Process - Application Pool Memory Issues

    Nov 20, 2019 11:14 AM|Rovastar|LINK

    This is known as a memory leak and sadly it is far to common but it not something that can always be fixed easily.

    Typically you are not getting up memory in your code, they are not competing the 'garbage collection' correctly. You will need the devs to look at that.

    You will need deeper support tools to point in the correct areas from an admin point of view.

    Troubleshoot IIS in style
    https://www.leansentry.com/
  • Re: IIS Worker Process - Application Pool Memory Issues

    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, etc.

    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.

    /charlie