[Users] memory leak in Carpet?
schnetter at cct.lsu.edu
Fri Aug 3 07:47:34 CDT 2018
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
Erik Schnetter <schnetter at cct.lsu.edu>
More information about the Users