Mapping the Memory Usage of .NET Applications: Part 1, Windows Memory Recap

To evaluate whether your application can scale with larger data sets and more concurrent users, you have to understand how it uses the memory available to it. Modern .NET applications (and especially mixed managed and native applications) have thousands of memory chunks across their address space—keeping track of these chunks manually in your head is an impossible endeavor.

First, a quick reminder about how virtual memory, managed heap allocations, and native heap allocations relate to each other (for more details, consider reading the Memory Manager chapter in Windows Internals):

    A Windows process has a virtual address space, which is a range of addresses your application can use. On 32-bit Windows, the address space available to your code is usually 2GB (roughly, the addresses 0x00000000 – 0x7FFFFFFF); on 64-bit systems, the address space available to your 64-bit process is 8TB.
    There is no requirement that enough physical memory (RAM) be available to support the virtual memory requirements of all applications. For example, you can install 2GB of physical memory on your PC and still run dozens of processes, each with a 2GB address space. Windows maps virtual addresses to physical addresses as demands dictate, and transfers data from physical memory to the disk (page file) to free physical memory space.
    Virtual memory can be allocated in two steps, using the VirtualAlloc Win32 API.
        You can tell Windows to reserve a chunk of virtual memory addresses—this reservation is very cheap, and doesn't incur any physical memory cost. Windows guarantees that no other component in your process will use the same address range.
        After reserving a chunk of memory, you can commit it—this is when you can start reading and writing to the allocated address range.

Read more: All Your Base Are Belong To Us
QR:

Posted via email from Jasper-net