6 Best Practices to Keep a .NET Application’s Memory Healthy

.NET Healthy Memory Management

Memory problems in a big .NET application are a silent killer of sorts. Kind of like high blood pressure. You can eat junk food for a long time ignoring it until one day you face a serious problem. In the case of a .NET program, that serious problem can be high memory consumption, major performance issues, and outright crashes. In this post, you’ll see how to keep our application’s blood pressure at healthy levels.

How do you know if you have healthy memory usage? And what do you need to do to keep it healthy? That’s exactly what this article is about. We’ll go over 6 best practices to keep memory healthy and to detect a problem if it occurs. You’ll also see best practices to optimize garbage collections and make your application very fast.

1. Objects should be collected as fast as possible

To make your program work fast, the prime objective is to have objects collected as soon as possible. To understand why it’s important, you need to understand .NET’s generational garbage collector. When objects are created with the new clause, they are created on the heap in Generation 0. That’s a very small space in memory. If they’re still referenced when there’s a Gen 0 collection, they are promoted to Gen 1. Gen 1 is a bigger memory space. If they’re still referenced when there’s a Gen 1 collection, they are promoted to Gen 2.

Gen 0 collections are the most frequent and are very fast. Gen 1 collections go over both Gen 0 memory space and Gen 1 memory space and they are more expensive. Gen 2 collections include the entire memory space including the Large Object Heap (LOH). They are extremely expensive. The GC is optimized to have many Gen 0 collections, fewer Gen 1 collections, and very few Gen 2 collections. But if you have many objects that get promoted to a higher generation then you’ll have the reverse effect. This leads to memory pressure (aka GC Pressure) and poor performance.

By the way, the allocations of new objects are extremely cheap. The only thing you need to worry about is the collections.

So how to have objects collected in a low generation? Simple, just make sure they aren’t referenced as quickly as possible. Some objects, like singletons, have to be in memory forever. That’s fine, they’re usually going to be services that don’t consume a lot of memory anyway.

2. Use caching… but carefully

Mechanisms like caching are troublesome by definition. Those are long-lived temporary objects that are probably going to be promoted to Gen 2. While that’s bad for GC pressure, it’s usually worth the price because caching can really help performance. But you have to keep an eye on it.

One way to relieve some of that memory pressure is by using mutable cache objects. That means that instead of replacing a cache object, you would update an existing object. Which will mean less work for the GC promoting objects and initiating more Gen 0 and Gen 1 collection.

Here’s an example. Let’s say you’re caching stock items from your online grocery store. You have a cache mechanism that stores prices and data for frequently queried items. Like those frozen pizzas that cause high blood pressure. Let’s say that every 5 minutes you have to invalidate the cache and re-query the database in case the details changed. So in this case, instead of creating a new Pizza object, you would change the state of the existing object.

3. Keep an eye on % Time in GC

If you want to find out just how much garbage collections hurt the execution time, it’s pretty easy to do. Simply look at the performance counter .NET CLR Memory | % Time in GC. That’s going to show which percent of the execution time is used by the garbage collector. There are many tools to look at performance counters. In Windows, you can use PerfMon. In Linux you can use dotnet-trace. To find out more, check out my article Use Performance Counters in .NET to measure Memory, CPU, and Everything.

I’m going to give you some magic numbers but take these with a grain of salt because everything has its own context. For a big application, 10% time in GC is probably a healthy percentage. 20% time in GC is borderline, and anything more means you have a problem.

4. Keep an eye on those Gen 2 Collections

Other than % Time in GC, the other big metric you should monitor is the number of Gen 2 collections. Or rather the rate of Gen 2 collections. The objective is to have as few of them as possible. Consider that those are full memory heap collections. They effectually freeze all threads of the application while the GC collects everything.

I can’t put a magic number on how many Gen 2 collections you should have. But I suggest to actively monitor for that number every once in a while, and if the rate rises then you probably added some very bad behavior. You can see that number with the performance counter .NET CLR Memory | % Gen 2 Collections

PerfMon showing Gen 2 collections

5. Monitor for steady memory consumption

Consider a regular state of an application. Some things happen all the time. It might be a server that serves requests, a service that pulls messages from a queue, a desktop application with a lot of screens. During this time your application constantly creates new objects, performs some operations, and then frees those objects and returns to a normal state. This means that memory consumption should be more or less the same in the long run. Sure, it might reach high levels in peak time or during heavy operation, but it should return to normal once it’s done.

But if you monitored a lot of applications you probably know that sometimes memory rises over time. The average consumption slowly rises to higher levels, even though it logically shouldn’t. The reason for that behavior is almost always memory leaks. That’s a phenomenon where an object isn’t used anymore but for some reason, it’s still referenced and thus never collected.

When an operation causes objects to leak, more memory is consumed with each such operation. With time, the memory rises. When enough time passes, the memory gets near its limit. In a 32-bit process that limit is 4GB. In a 64-bit process, it depends on the machine constraints. When we’re so near the limit, the garbage collector panics. It starts triggering full memory Gen 2 collections for every other allocation so as not to run out of memory. This can easily slow down your application to a crawl. When even more time passes the memory does reach its limit and the application crashes with a catastrophic OutOfMemoryException. There you have it—the equivalent of a heart attack.

To make sure you don’t reach this state of affairs, my advice is to actively monitor for memory consumption over time. The best way to do that is to look at the performance counter Process | Private Bytes. You can do it easily with Process explorer or with PerfMon.

6. Periodically look for memory leaks

The #1 culprit of memory problems is without any doubt memory leaks. It’s easy to cause them, they can be ignored for a long time, and they cause a ton of damage eventually. Fixing memory leaks at the stage your application crashes consistently is very difficult. You’ll have to change old code which can cause all sorts of regression bugs. So I would add a second prime objective to an application with healthy memory: Fix and avoid memory leaks.

It’s not realistic to expect your team to never introduce memory leaks. And it’s not practical to check for memory leaks throughout the application with each new commit. Instead, I suggest adding the practice of checking for memory leaks every once in a while. It might be weekly, monthly, or quarterly. Whatever works for you.

One way to go about it is to check for memory leaks every time you see rising memory (as suggested in Tip #5). But the problem with that is that leaks that have a low memory footprint also cause a lot of issues. For example, you might have objects that should have been collected but remain alive and still have code executing in them, which results in incorrect behavior.

The best way to detect and fix memory leaks is by using a memory profiler. See how to do that in my article Demystifying Memory Profilers in C# .NET Part 2: Memory Leaks.

To see what kind of design patterns lead to memory leaks, check out my article 8 Ways You can Cause Memory Leaks in .NET.

Summary

So there you have it, a recipe for a healthy memory state. If you follow those recommendations, your application will be fast and consume little memory. But seriously though, please eat healthy food and exercise 🙂

Share:

Enjoy the blog? I would love you to subscribe! Performance Optimizations in C#: 10 Best Practices (exclusive article)

Want to become an expert problem solver? Check out a chapter from my book Practical Debugging for .NET Developers

20 thoughts on “6 Best Practices to Keep a .NET Application’s Memory Healthy”

  1. Excellent post. I was checking constantly this blog and I am impressed! Extremely helpful information specifically the last part 🙂 I care for such info a lot. I was looking for this certain info for a long time. Thank you and good luck.

  2. I used to be suggested this web site through my cousin. I’m not positive whether or not this put up is written by him as nobody else realize such certain approximately my trouble. You are amazing! Thanks!

  3. This web site can be a stroll-through for all of the information you needed about this and didn’t know who to ask. Glimpse here, and you’ll undoubtedly discover it.

  4. certainly like your web-site however you have to take a look at the spelling on several of your posts. A number of them are rife with spelling problems and I in finding it very bothersome to inform the reality nevertheless I will certainly come back again.

  5. I’m not sure why but this web site is loading incredibly slow for me. Is anyone else having this issue or is it a issue on my end? I’ll check back later on and see if the problem still exists.

  6. Undeniably believe that which you said. Your favourite justification seemed to be at the net the simplest thing to have in mind of. I say to you, I certainly get annoyed at the same time as folks consider worries that they just don’t understand about. You managed to hit the nail upon the highest and outlined out the entire thing with no need side-effects , other folks can take a signal. Will likely be again to get more. Thanks

  7. I’m really inspired along with your writing abilities as well as with the format for your weblog. Is this a paid subject matter or did you customize it yourself? Anyway keep up the excellent high quality writing, it is uncommon to see a great blog like this one today.

  8. I carry on listening to the news bulletin speak about receiving free online grant applications so I have been looking around for the top site to get one. Could you advise me please, where could i get some?

  9. A powerful share, I just given this onto a colleague who was doing just a little analysis on this. And he in fact bought me breakfast as a result of I found it for him.. smile. So let me reword that: Thnx for the treat! However yeah Thnkx for spending the time to discuss this, I really feel strongly about it and love reading more on this topic. If doable, as you turn out to be expertise, would you mind updating your blog with extra particulars? It is extremely useful for me. Big thumb up for this blog publish!

Comments are closed.