IIS (10.0.19041.1) worker process (w3wp.exe) do not release memory!

IIS (10.0.19041.1) worker process (w3wp.exe) do not release memory!

Posted by: s3india1994 on 8 February 2022, 12:00 am EST

• 

  s3india1994

  • Post Options:
  • Link
    Copy

  Posted 8 February 2022, 12:00 am EST

  IIS (10.0.19041.1) worker process (w3wp.exe) do not release memory! Some times it do, but when it crosses 2.5 GB then its memory remains there. What to do? Need urgent resolution as we are facing this issue @ customer location.

  System have 64 GB RAM and high end processor Windows server 2019. Although i have tested the same scenario with Windows 10 and same issue exists.

  Currently i have Enabled recycle the applictaion pool setting when it cross 2.5 GB space for workaround but this will be declared failed soon.

  I am using the existing default WebAPI solution!

  This issue can occurs frequently when we open report with 5K + records and keep refreshing the report continuously.

  In ReportsRoot Folder of bundle(From WebAPI build) i put flexreports files (.flxr) designed from C1Flexreportdesigner.

  So I host bundle folder with reports file in ReportsRoot/ in IIS Server.

  Now I use Wijmo Viewer to get get reports list from iisserver/bundle website and hence report data is fetched.

  My Reports contains DSN of Database(Postgres).

• 

  manish.gupta

  

  • Post Options:
  • Link
    Copy

  Posted 15 February 2022, 10:27 pm EST

  Hi,
  
  We are sorry for the delayed response. As per our understanding, you have a WebAPi ReportService where you have hosted your own FlexReport to show case in the Viewer. Now the Viewer is part of other project.

  So architecture is like as follows:

  Viewer Project ===> API Project (report request) ==> viewer project

  In this case, when you refreshes the page again and again and it cause the memory issues in IIS where the application is hosted.

  We tried to replicate the same at our end but we are unable to replicate the issue at our end. Is there any specific steps to replicate the issue at our end.

  Regards,
  
  Manish Gupta