[Users] memory leak in Carpet?
Miguel Zilhão
miguel.zilhao.nogueira at tecnico.ulisboa.pt
Mon Jul 23 08:00:56 CDT 2018
hi Ian and all,
>>> This could be caused by memory fragmentation due to all the freeing and mallocing that happens
>>> during regridding when the sizes of the grids change. Can you try using tcmalloc or jemalloc
>>> instead of glibc malloc and reporting back? One workaround could be to run shorter simulations
>>> (i.e. set a walltime of 12 h instead of 24 h).
>>
>> thanks for your reply. in one of my cases, for the resolution used and the available memory, i was
>> out of memory quite quickly -- within 6 hours or so... so unfortunately it becomes a bit
>> impractical for large simulations...
>>
>> what would i need to do in order to use tcmalloc or jemalloc?
>
> I have used tcmalloc. I think you will need the following:
>
> - Install tcmalloc (https://github.com/gperftools/gperftools), and libunwind, which it depends on.
> - In your optionlist, link with tcmalloc. I have
>
> LDFLAGS = -rdynamic -L/home/ianhin/software/gperftools-2.1/lib
> -Wl,-rpath,/home/ianhin/software/gperftools-2.1/lib -ltcmalloc
>
> This should be sufficient I think for tcmalloc to be used instead of glibc malloc. Try this out,
> and see if things are better. I also have a thorn which hooks into the tcmalloc API. You can get
> it from
thanks a lot for these pointers. i've tried it out, though i've used tcmalloc from ubuntu's
repositories and therefore compiled ET with -ltcmalloc_minimal. i don't know whether this makes a
difference, but from the trial run that i'm doing i so far seem to see the same memory increase i
had seen before...
is there anything else that can be tried to try to pinpoint this issue? it seems to be serious... i
looked for an open ticket but didn't find anything. shall i submit one?
thanks,
Miguel
More information about the Users
mailing list