<html>#2194: Memory increase during regridding
<table style='border-spacing: 1ex 0pt; '>
<tr><td style='text-align:right'> Reporter:</td><td>Wolfgang Kastaun</td></tr>
<tr><td style='text-align:right'> Status:</td><td>open</td></tr>
<tr><td style='text-align:right'>Milestone:</td><td>ET_2019_02</td></tr>
<tr><td style='text-align:right'> Version:</td><td>development version</td></tr>
<tr><td style='text-align:right'> Type:</td><td>bug</td></tr>
<tr><td style='text-align:right'> Priority:</td><td>minor</td></tr>
<tr><td style='text-align:right'>Component:</td><td>Other</td></tr>
</table>
<p>Comment (by Ian Hinder):</p>
<p>I would be very careful interpreting the SystemStatistics memory information. From what I know, the mallinfo data structure from glibc is not even 64-bit safe (the ints are 32 bit). Much better, if you really want a reliable way to see what is happening, would be to use tcmalloc, and then output the diagnostics it provides. I wrote a tcmalloc wrapper thorn which outputs the diagnostics to files during a Cactus run (<a data-is-external-link="true" href="https://bitbucket.org/ianhinder/tcmalloc/src/master/" rel="nofollow">https://bitbucket.org/ianhinder/tcmalloc/src/master/</a>). The thorn doesn’t install tcmalloc for you, so you have to do that yourself, but it’s fairly easy (you do need libunwind as a dependency). The thorn has a parameter to force tcmalloc to release memory back to the OS after each regridding. </p>
<ul>
<li>Install tcmalloc (<a href="https://github.com/gperftools/gperftools" rel="nofollow" class="ap-connect-link">https://github.com/gperftools/gperftools</a>), and libunwind, which it depends on. </li>
<li>
<p>In your optionlist, link with tcmalloc. I have</p>
<div class="codehilite"><pre><span></span>LDFLAGS = -rdynamic -L/home/ianhin/software/gperftools-2.1/lib -Wl,-rpath,/home/ianhin/software/gperftools-2.1/lib -ltcmalloc
</pre></div>
</li>
</ul>
<p>This should be sufficient for tcmalloc to be used instead of glibc malloc. </p>
<p>Also note that a high maxrss is not necessarily a problem; it might just mean the OS didn’t need that memory yet, and therefore hasn’t unmapped it.</p>
<p>--<br/>
Ticket URL: <a href='https://bitbucket.org/einsteintoolkit/tickets/issues/2194/memory-increase-during-regridding'>https://bitbucket.org/einsteintoolkit/tickets/issues/2194/memory-increase-during-regridding</a></p>
</html>