[Users] memory leak in Carpet?
miguel.zilhao.nogueira at tecnico.ulisboa.pt
Fri Aug 3 09:25:52 CDT 2018
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.
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.
> 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.
>> 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:
>>>> 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
>> Users mailing list
>> Users at einsteintoolkit.org
More information about the Users