Now that we had a snapshot, we opened it in dotMemory.
So we waited until we had enough data and then pressed Ctrl+C. In our case, we had to stop profiling manually (because otherwise we would have ended up swapping again). It captures a snapshot as soon as the volume of “private bytes” reaches 20 GB, and after the profiling completes it opens the snapshot in dotMemory. This command launches dotMemory.UI.64.exe in profiling mode. The dotMemory console profiler was the best tool for the job: That is why we decided to take the snapshot when memory use begins to grow quickly, but there’s still some physical memory left. Even the operating system becomes unstable. Once a process has completely exhausted physical memory, capturing a snapshot is no easy task. And so, the time had come to use dotMemory to fix a problem in dotMemory. When that happens, it usually means you won’t receive your results in an adequate time frame. Thankfully, the problem was internal, so we collected a memory snapshot and began looking into it.Īs soon as we reproduced the problem on a local machine, we saw that at some point memory use began growing rapidly at the speed of 1.17 GB per second, forcing the process to begin using a swap file. The data for that tree was taking too long to compute – so long, in fact, that his patience ran out before the process could complete. It all began when a colleague messaged me in Slack about a problem he was experiencing with the dominator tree in dotMemory. I’d like to thank the authors of two articles, 1 and 2, which inspired me to share this story. We then improved it some more using dotTrace, and finished off the optimization process by using BenchmarkDotNet. I’d like to tell you a classical dogfooding story of how we optimized one of dotMemory’s algorithms by using our own tools – dotMemory and dotTrace. My name is Ilya and I help develop the tool.
0 kommentar(er)
