In this article, we’ll see how GC activity can cause major performance problems. This phenomenon is called Memory Pressure and we’ll see how to deal with it using memory profilers.
Memory leaks are very common, hard to notice, and eventually, lead to devastating consequences. The main tool to detect and fix memory leaks is a Memory Profiler. In fact, I believe the most common usage of memory profilers in .NET is exactly for the purpose of fixing memory leaks. In this article, you’ll see exactly how to use memory profilers to find the leaky objects, why they are still referenced, and how to solve the problem.
Memory leaks and GC Pressure cause pretty inconvenient effects like out-of-memory crashes, performance problems, and high memory consumption. Our primary tools when dealing with those issues are memory profilers. They are one of the most important category of tools in .NET troubleshooting, and in this article, you’ll see how to use them and extract the most information from them.
It’s not so rare to see weird things happen in 3rd party library code. Call some method and you’ve got a strange exception. Or an incorrect behavior or even a process crash. It sure would be nice to debug some of these issues. In this article we’re going to do just that – You’ll see how to debug 3rd party library code in Visual Studio.
Lock contention is a state where one thread is waiting for another while trying to acquire a lock. Whatever time spent waiting for the lock is “lost” time that is wasted doing nothing and causes performance problems. In this article, you’ll see how to detect lock contention problems, debug them, and find the core cause of the issue.