This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

w3wp.exe using 1+ gig of memory after NPM 9.5 update.

We updated one of our environments to NPM 9.5 and since then we have the Orion web site going array. W3wp.exe will get upwards of 1+ gig of memory used and eventually take down the Primary until I go in and restart the Orion Web services and kill the 1+ gig w3wp.exe file.

This last incident had w3wp.exe running 1.7 gig on a box with 4 gig total memory. this is also in a development environment that only had 5 people hitting the site.

As I stated, this has been an issue since installing NPM 9.5 and still there up to SP4. I have had a few tickets open with Solarwinds and nothing seems to work as of yet. Steps taken so far : NPM 9.5 repair/re-install, replace the JobEngine35.sdf, re-installed SWJobEngine/InformationService, adjusted Application Pools in IIS to recycle every hour, and even updated the OS on the server.

I have case # 115722 open on this issue.

Any ideas/suggestions ?

  • This is still present in SP4?  Please get your diagnostics and send them to us also.

    John Taylor

  • Hey Mate,

     

    I have the same issue, and when the process his 1Gig I have to restart the process, with this using a high proportion of memory and bussiness layer eating the CPU im waiting for the server to melt.

     

    SP4 has not rectified the issue.

     

    Miron

  • do you use reports? if so, does removing them from the website help?

  • Yes I have a few custom reports on the front end. I will create a new view and try without any of the reports, just the normal resources.

    If the reports being displayed on the web is what is causing the issue, then its going to be a huge step backwards for us. We modified a few of the resources previous to 9.5 to display the information in a fashion that was useful and easy to read for us. I can not find a way to do the same in 9.5 other then utilizing reports and the report resource.

  • Well.. that seems to be what is causing the issue.

    Problem is I am in square one again. I am now back to a website with a jumble of information, no longer can we just glance at any given resource and see what we need.

    Is the issue with reports a "bug" or just how it works when you have reports on the site ? Any tips/suggestions/recommendations ?

  • Recycling the application pool every time the memory usage exceeds (let's say) 400MB might help. This should be available option in the IIS manager.

  • I have tried that, didn't work.

    Is the high memory usage/hangs normal for the report resource ? Is there a suggested limit to how many reports I should post ? Is this a bug ?

  • We had the same issue when we went from 9.1 SP5 to 9.5 SP1.  The website would be unresponsive every day, almost every hour.  it was getting ridiculous.  We would go in and stop the IIS services, and that seemed help. 
    Then we noticed if we just open task manager on the server, and kill w3wp.exe, that would bring the website back. 
    So for the past month, on a daily, sometimes hourly, basis, we have been ending w3wp.exe.

    Just last week I noticed in IIS that Orion had 2 websites running.  NPM and NCM.  Since NCM is now integrated into NPM website, the NCM site must have been residual from back when NCM was its own website.
    I stopped the NCM website from running, and have not had to restart anything since.  the NPM website has been responsive now for over a week.  First time that has happened since 9.1.
    Just wondering, if anyone is still having the unresponsive NPM website can try what is described and see if that helps.
    Thanks

  • We're having the same issue with both our main and "additional web server".  It happens more on the AWS, which is where most clients go to, so I think its related to the # of connections.   We do have reports enabled, but not for most clients, and I seriously doubt that anyone is doing them on a regular basis...