[Users] memory leak in Carpet?

Miguel Zilhão miguel.zilhao.nogueira at tecnico.ulisboa.pt
Fri Aug 3 03:49:18 CDT 2018

hi Ian,

sorry, i thought it was enough to see the qualitative trend of the curves... here's what i hope to 
be a better plot, with all the information.
also, i have no hdf5 output for this run. i'm only saving plain text.


On 02/08/2018 23:31, ian.hinder at aei.mpg.de wrote:
>> On 2 Aug 2018, at 18:55, Miguel Zilhão <miguel.zilhao.nogueira at tecnico.ulisboa.pt 
>> <mailto:miguel.zilhao.nogueira at tecnico.ulisboa.pt>> wrote:
>> yes, sorry. here are the labels from the tcmalloc file:
>> 3:generic_current_allocated_bytes
>> 4:generic_heap_size
>> 5:tcmalloc_pageheap_free_bytes
>> 6:tcmalloc_pageheap_unmapped_bytes
>> column 5 (tcmalloc_pageheap_free_bytes) is not visible in the plot since it's flat zero.
> Hi Miguel,
> It is very hard to see what is going on, because I am having to look in two different plots, with 
> different plot ranges, and a second email with the column number definitions.
> Please can you help me to help you by organising the information a bit more clearly?
> It would be good to see a single plot showing all of the data, with a legend that shows what each 
> line is.  I assume that $6 in carpet-memory_procs is gridfunctions, but please check that and 
> include the information in the plot.  Also, please set the plot y axis range to start at zero; it's 
> hard to see what's going on because the two plots have different ranges, and very confusing that one 
> of them is not zero.
>  From what I can tell at the moment, the new gridfunction data takes less memory than the old after 
> the regridding, but the rss grows dramatically.  The allocated memory also grows dramatically, 
> suggesting a memory leak, but not enough to account for the growth in rss.  It's possible that 
> something other than regridding is responsible.  Do you have any HDF5 output enabled that might 
> coincide with iteration 2048?  HDF5 might be allocating buffers on first output that are then not 
> freed because they will be used again later.  Can you disable all output and see what happens?
> -- 
> Ian Hinder
> https://ianhinder.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: memory.pdf
Type: application/pdf
Size: 14810 bytes
Desc: not available
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20180803/419702f4/attachment-0001.pdf 

More information about the Users mailing list