What do the following numbers mean?

Simon Marlow marlowsd at gmail.com
Tue Apr 10 13:19:29 CEST 2012


On 03/04/2012 00:46, Ben Lippmeier wrote:
>
> On 02/04/2012, at 10:10 PM, Jurriaan Hage wrote:
>> Can anyone tell me what the exact difference is between
>> 1,842,979,344 bytes maximum residency (219 sample(s)) and 4451 MB
>> total memory in use (0 MB lost due to fragmentation)
>>
>> I could not find this information in the docs anywhere, but I may
>> have missed it.
>
> The "maximum residency" is the peak amount of live data in the heap.
> The "total memory in use" is the peak amount that the GHC runtime
> requested from the operating system. Because the runtime system
> ensures that the heap is always bigger than the size of the live
> data, the second number will be larger.
>
> The maximum residency is determined by performing a garbage
> collection, which traces out the graph of live objects. This means
> that the number reported may not be the exact peak memory use of the
> program, because objects could be allocated and then become
> unreachable before the next sample. If you want a more accurate
> number then increase the frequency of the heap sampling with the
> -i<sec>  RTS flag.

To put it another way, the difference between "maximum residency" and 
"total memory in use" is the overhead imposed by the runtime's memory 
manager.

Typically for the default settings the total memory in use will be about 
three times the maximum residency, because the runtime is using copying 
GC.  If your maximum residency is L (for Live data), and we let the heap 
grow to size 2L before doing a GC (the 2 can be tuned with the -F flag), 
and we need another L to copy the live data into, then we need in total 3L.

This assumes that the live data remains constant, which it doesn't in 
practice, hence the overhead is not always exactly 3L.  Generational GC 
also adds some memory overhead, but with the default settings it is 
limited to at most 1MB (512KB for the nursery, and another 512KB for aging).

Cheers,
	Simon



More information about the Glasgow-haskell-users mailing list