[Users] memory leak in Carpet?

Miguel Zilhão miguel.zilhao.nogueira at tecnico.ulisboa.pt
Fri Aug 3 09:25:52 CDT 2018


hi Erik,

i've just tried without CarpetIOASCII and i'm seeing the same pattern. the only output i have now is 
CarpetIOScalar (for the memory profiles) and AHFinderDirect's BH_diagnostics.ah?.gp files.

thanks,
Miguel

On 03/08/2018 13:47, Erik Schnetter wrote:
> 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
>>
> 
> 
> 


More information about the Users mailing list