High Memory Usage or Memory Leaks in Web Applications: Understanding and Data Collections

  • Thread starter Thread starter HridayDutta
  • Start date Start date
H

HridayDutta

Introduction​


High memory usage or memory leaks is a common challenge for the web applications. The unanticipated memory consumption can lead to performance bottlenecks, system crashes, and degraded user experiences. In this article, we will explore the concept of high memory usage, how to identify it, various types of high memory issues and how to collect logs for analysis.



Identifying high memory​


The simplest way to identify high memory is to check the Private Bytes. Private Bytes indicates the amount of private committed memory being used by the process. Making it the key counter to rely on when determining if high memory consumption is happening for the application.



IIS Manager: You can check the Private Bytes form the IIS Manager Worker Process module. The private bytes displayed here is in KB.

HridayDutta_9-1726514493172.png



Task Manager: You can get the same information from Task Manager Details tab. Find the worker process(w3wp.exe) that match the user name for that application pool. You need to look for Memory (active private working set). You will get the private bytes consumed by the application in KB.

HridayDutta_10-1726514631115.png



Performance Monitor: Performance Monitor is a great tool to verify high memory usage.

  • Open Performance Monitor
  • Click Add
  • Expand Process
  • Select Private Bytes
  • And choose the worker process (w3wp).

HridayDutta_11-1726514671180.png

Also add the following counters -

  • Virtual Bytes, you can find the Virtual Bytes under Process tree.
  • #Bytes in all Heap, you will find the #Bytes in all Heap under .NET CLR Memory.

These counters will help you to identify the memory leaks. And it will also tell you whether a leak is a native leak or a managed leak.



Native Memory Leaks: If the private bytes counter is increasing but the .NET bytes in all heaps counter remains constant. This indicates a native memory leak.

HridayDutta_12-1726514748634.png



Managed Memory Leaks: If the private bytes counter and the .NET bytes in all heaps counter are increasing at the same rate (the difference between the two remains constant).

indicates a managed memory leak.

HridayDutta_13-1726514785777.png



Log Collection​


Now that you're familiar with how to confirm high memory and use counters to distinguish between native and managed memory leaks, the next step is to correctly collect logs. In most cases, a full user dump is sufficient for analyzing high memory or memory leaks. However, the process for collecting dumps differs between native and managed leaks.



Native Memory Leaks


HridayDutta_14-1726514946030.png



This will generate a full user dump, and you should create three of them for proper analysis and comparison.



You can automate this process if the issue is intermittent or you don’t want to monitor it.

  • Open DebugDiag 2 Collection.
  • Click on Add Rule
  • Select Native (non-.NET Memory and handle Leak)
  • Click Next
  • Select the worker process (w3wp.exe)
  • Click Configure and set provide the parameters as in below screenshot.

HridayDutta_15-1726514979889.png

The above parameters will create the first memory dump of 800 MB. Two more dumps will be created at the increments specified - i.e. 1000 (800+ 200) and 1200 MB. Then the final memory dump will be created 15 minutes after tracking.



Managed Memory Leaks


HridayDutta_16-1726515021862.png

  • Select and set the below options, do not click "Save & Close" at this point.
  • Wait for memory consumption to raise to decided level (70 to 80%).
  • Click Save & Close

HridayDutta_17-1726515049996.png



You can automate this process using the ProcDump utility.

  • Download Procdump.exe from thi official download link - ProcDump - Sysinternals | Microsoft Learn
  • Extract the zip files into a folder of your choice.
  • Open command prompt with administrator privilege and navigate to the folder.
  • Execute the below command.



procdump.exe -s 30 -m 1000 -ma -n 3 <PID>



-n number of memory dumps

-m Memory commit threshold in MB at which the dumps will be created

-s would indicate the number of consecutive seconds where memory consumption was >= threshold specified with -m

PID is the process id for the worker process.



.NET Core applications

If the app in question is .NET Core and hosted on IIS in-process mode, then this above option applies as is. But if the app is hosted on IIS as out-of-proc mode then the action plan should be modified so that the dotnet process(dotnet.exe unless otherwise specified) is investigated instead of w3wp.exe. Same thing applies self-hosted .NET Core applications.



Conclusion​


High memory usage or memory leaks is a complex issue with many potential causes, it can be native or managed. It is very important to isolate the type of memory leaks and carefully capture the logs. You can analyze the dumps using tools like WinDbg or DebugDiag2 Analysis. If you want us to do that, please contact us with a case and we will do it for you.

Continue reading...
 
Back
Top