High Memory Usage or Memory Leaks in Web Applications: Identification and Log Collection

introduction

High memory usage or memory leaks are a common problem for web applications. Unexpected memory consumption can lead to performance bottlenecks, system crashes, and poor user experiences. In this article, we will look at the concept of high memory usage, how to identify it, the different types of high memory issues, and how to collect logs for analysis.

High memory identification

The simplest way to identify high memory is to check: Private Byte. Private Bytes represents the amount of private committed memory used by the process. This is a key counter to rely on when determining whether your application is experiencing high memory consumption.

IIS Manager: You can check Private Bytes in the Worker Process module of IIS Manager. The private bytes shown here are in KB.

Task Manager: The same information can be obtained from: Task Manager details Tab. Find worker processes (w3wp.exe) matches the user name of the application pool in question. You should find it. Memory (Active Private Working Set)You will receive the number of private bytes used by your application in KB.

Performance Monitor: Performance Monitor is a useful tool for identifying high memory usage.

• open Performance Monitor
• Clicking sound add
• Expand process
• Choose Private Byte
• And select the worker process (w3wp).

Also add the following counters:

• Virtual bytesYou can find virtual bytes in the process tree.
• # bytes of all heapsYou can find #Bytes in all heaps under .NET CLR memory.

These counters help identify memory leaks. They also help identify Native leak or Managed Leaks.

Native memory leak: If the private byte counter increases but the .NET byte counters for all heaps remain constant, this indicates a native memory leak.

Managed memory leak: If the private byte counter and the .NET byte counter for all heaps increase at the same rate (the difference between the two remains constant).

Indicates a managed memory leak.

Log collection

Now that you know how to identify high memory and use counters to differentiate between native and managed memory leaks, the next step is to collect the logs correctly. In most cases, a full user dump is sufficient to analyze high memory or memory leaks. However, the process of collecting the dump differs between native and managed leaks.

Native memory leak

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

If the problem occurs intermittently or you don’t want to monitor it, you can automate this process.

• open DebugDiag 2 Collection.
• Click here Add a rule
• Choose Native (non-.NET memory and handle leaks)
• Clicking sound next
• Select a worker process (w3wp.exe)
• Click on Configure and provide parameters as shown in the screenshot below.

The above parameters will generate the first memory dump of 800MB. Two more dumps will be generated based on the specified increments: 1000(800+200) and 1200MB. Then the final memory dump will be generated 15 minutes after the trace.

Managed memory leak

• Select and configure the options below. Do not click “Save & Close” At this point.
• Wait until memory consumption increases to a certain level (70-80%).
• Clicking sound Save and Close

This process can be automated using: Prokdump Public service.

• Download Procdump.exe From this official download link – ProcDump – Sysinternals | Microsoft Learn
• Extract zip file Put it in the folder you want.
• open Command Prompt Go to that folder with administrator rights.
• Run the command below.

procdump.exe -s 30 -m 1000 -ma -n 3 

-N Number of memory dumps

-middle Memory commit threshold (MB) at which dumps will be generated

-S -Indicates the number of consecutive seconds during which memory consumption is greater than the threshold specified by -m.

PD is the process ID of the worker process.

.NET Core Application

If the app in question is .NET Core and hosted on IIS In progress If the mode is on, the above options will still apply. However, if the app is hosted on IIS, Outside the process When the mode is on, the work plan needs to be modified so the dotnet process (dotnet.exe (unless otherwise specified) is investigated instead. w3wp.exe. The same applies Self-hosting .NET Core application.

conclusion

High memory usage or memory leaks are complex issues with many potential causes, and can be native or managed. It is very important to isolate the type of memory leak and capture the logs carefully. You can use tools such as the following to analyze the dumps: Windy Bizz or DebugDiag2 AnalysisIf you would like us to do this for you, please contact us with your case and we will do it for you.