Welcome to EMC Consulting Blogs

Memory Optimization in .NET

When Memory Affects Time

• If your computation is not local, memory matters
• Cold start up: at first all code is from disk
• Disk can transfer at best 50mb/sec, worst 1meg/sec
• However OS caches disc (thus only new code is bad)
• Sluggishness is when App Switching
• Start App1
• User Switches to App2
• App 2 “steals” physical memory of App1 (paged out)
• User switches back to App1, memory must be paged in
• Servers are constantly “app switching”

Memory breakdown of a .NET app

• Memory mapped files (mostly shared)
• Loaded DLLs
• Code / Read Only data (can be shared)
• Read / write data (private to one process)
• Other mapped files (fonts, registry)
• Dynamic data (not shared)
• Unmanaged heaps
• Stack
• System support (VM Page Entries, TEB – represents thread)
• Direct VirtualAlloc calls
• Runtime’s Garbage Collected (GC) Heap

Tools for viewing memory usage

• Task Manager
• Working Set – shared – overestimates memory impact (OS Shared Files), does not account for read files
• Private Working Set – not shared – underestimates impact
• PerfMon (launch using - Win-R “perfmon”)
• Add new counters
• Add - Bytes in all heaps
• Add - Gen 0, 1 ,2 Collections
• Select “running” application – this is a gotcha
• % time in GC should be <10
• VADump
• VaDump –sop ProcessID
• Tells you every page that exists for that process
• Provides breakdown of Code Static Data / Heap / Stack / Teb, Mapped Data, Other Data
• Code Static Data – affects start-up as this is I/O bound.

Typical Memory Breakdown Results

• Memory is mostly from DLL Loads
• Typically cold start up is very bad (since data must come from disk)
• Private + shareable but not shared is the metric of interest
• Eliminating unnecessary (unshared) DLL loads first attack
• See CLR Performance Team blog on tracking down SDLL loads
• Eliminating amount of code touched is next

Fixing memory Issues: Prevention!

• Fixing memory issues is HARD
• Usually a DESING problem: Not Pay for Play
• Using every new feature in your app
• XML, LINQ, WPF, WCF, Serialisation
• Initialise all your subsystems at start up
• GC Memory Are your Data Structures
• Tend to be designed early
• Hard to change later
• Think about memory EARLY

Some Theory on the .NET GC HEAP

• GC Heap looks like a saw tooth
• Typical Gen 2 Peak, trough is ~1.6
• Ratio mostly independent of the heap size
• Keep in mind no other fragmentation