[Users] memory leak in Carpet?

[Erik Schnetter]

In addition to HDF5, traditionally CarpetIOASCII triggered memory
leaks in libc. CarpetIOASCII is special in that only a single process
performs I/O and thus uses much more memory than the others. You could
test a run with CarpetIOASCII disabled.

-erik

On Fri, Aug 3, 2018 at 4:49 AM, Miguel Zilhão
<miguel.zilhao.nogueira at tecnico.ulisboa.pt> wrote:
> 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.
>
> thanks,
> Miguel
>
> 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
>>
>
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users
>



-- 
Erik Schnetter <schnetter at cct.lsu.edu>
http://www.perimeterinstitute.ca/personal/eschnetter/