How to Capture and Analyze a Memory Dump for VirtoCommerce on Linux

dev
1

Overview

When troubleshooting high memory usage or potential memory leaks in VirtoCommerce Platform, it’s often necessary to capture a full memory dump of the running .NET process and analyze the heap contents.
This guide describes how to collect and analyze a dump file on Linux, using the official .NET diagnostics tools.

1. Identify the VirtoCommerce Process

First, find the process ID (PID) of the running VirtoCommerce Platform application.

ps aux | grep dotnet

Example output:

dotnet /var/www/virtocommerce/VirtoCommerce.Platform.Web.dll

Note the PID (e.g. 12345) for the next step.

2. Collect the Memory Dump

Run the following command to capture the heap dump:

dotnet-dump collect -p <PID> --type Heap

Replace <PID> with your actual process ID.

This command will create a dump file (e.g. core_20251007_123456.dmp) in the current directory.

:light_bulb: Note: The --type Heap option ensures that the full managed heap is captured.

3. Install .NET Runtime (if needed)

If you see an error that dotnet-dump is not available, install the required .NET runtime tools:

sudo apt-get install -y dotnet-runtime-8.0

Then retry the dotnet-dump command.

4. Analyze the Dump (Linux only)

:warning: Important:
Memory dumps captured on Linux can only be analyzed on Linux.
You cannot open Linux dumps in Visual Studio on Windows.

Use the following command to start interactive analysis:

dotnet-dump analyze memory.dmp

Once the analyzer loads, you can use commands similar to WinDbg:

  • List heap statistics:

    dumpheap -stat

This will show a summary of all objects on the managed heap, including type names, object counts, and total memory size.
Example:

image
image1038×579 67.4 KB

5. Why Not Use dotnet-gcdump?

Although dotnet-gcdump produces smaller files, it often yields incomplete or inaccurate data in real-world use.
In several internal investigations, the dotnet-gcdump output showed incorrect object counts and unrealistic heap sizes (sometimes exceeding terabytes).

For this reason, we recommend using dotnet-dump collect instead. It provides full and reliable information about the managed heap structure.

1 Like