Unable to save memory snapshot (64GB+ memory usage)



I'm working on an application with a large memory footprint (64GB+ - physical ram).


I'm trying to profile the memory usage through DotMemory, yet the "saving snapshot" process never ends.


Is DotMemory capable of handling the profiling of applications with a large memory usage ?  Are there any logs I can provide you with ?


Note: I'm attaching to the application. I assume starting the process from DotMemory (instead of attaching) and using the API to limit the profiling scope won't change anything, but I'll get it a try...

Comment actions Permalink

Well, I freed up some disk space and some RAM and the snapshot finally got to save... Now the remaining issue is the excruciatingly long processing time of the snapshot, which makes analyzing the results impossible.

I'm going to assume DotMemory is not designed to handle large memory dumps ? I frankly can't click on anything without waiting hours for results, if any at all.

Comment actions Permalink


Could you please send us your workspace? You can upload it to our ftp: https://uploads.services.jetbrains.com/

Also provide some more information:

- What dotMemory version do you use?
- How many objects exist in the snapshot after processing is finished?
- Could you please send us a screenshot with long view loading?

Comment actions Permalink

Hi Anna,


Thank you for the reply.


>> What dotMemory version do you use?

I used DotMemory 2019.3.4

>> How many objects exist in the snapshot after processing is finished?

483.15M :) (yes, million)

>> Could you please send us a screenshot with long view loading?

Please see the screenshot attached to this post.

Comment actions Permalink

Note: This is a financial application, hence the high memory usage. Decimals are used instead of double, etc.

The workspace is being zipped as we speak... I'll update the post when it's uploaded.

Comment actions Permalink

We have known issue with "find shortest retention paths" algorithm, it become O(n^2) s the case when object graph has a "bad" topology (not in all cases) and works very slowly. Probably your case is the same, we'll say exactly when check your workspace. Thus, retention-related views can require a lot of time in some cases.

We have a plans to make this algorithm parallel (see DMRY-7466).

Please describe your approximate steps what views did you open in this snapshot?

Comment actions Permalink

Thank you for the detailed reply, I appreciate it.

>> Please describe your approximate steps what views you opened in this snapshot?

Opening any view yields the same result: either an unresponsive window, or a blank window with a progress bar in the bottom right.

Regarding the workspace, the upload seems unreliable (11 GB zipped workspace) - could I please put the .zip file on any other storage platform ? (dropbox, etc.)

Comment actions Permalink

Yes, you can upload it to dropbox.


Please sign in to leave a comment.