<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>I just want to reiterate what Jason has said below. I recently spent several months trying to reduce the amount of memory used by one of our applications. We were seeing efficiency ratings for the heap in the 50-60% range (in terms of VM use vs outstanding
buffers used by the app).</div>
<div><br>
</div>
<div>In our case it was relatively easy to segregate one of the largest offenders (a periodic thread that consumes large amounts of heap and then frees it when finished). This resulted in a very large efficiency gain (now closer to 90%). If you are able to
segregate long lived allocations I don't think it matters how many transient arenas you have configured because over time they'll empty themselves.</div>
<div><br>
</div>
<div>Also, another use for arenas we are interested in trying but haven't explored is fault isolation. Again this will depend a bit upon your application, but one idea is to assign a problem thread or module its own arena in order to pinpoint the source of
memory corruption issues. In reduced memory environments tools like valgrind aren't always an option so something much lighter weight like thread specific arenas seem likely to be more viable.</div>
<div><br>
</div>
<div>We are using a fairly old version of jemalloc. I'm happy to see that the newer version has official support for this type of segregation. In the version we are using we also had to modify the code that detects when there's contention for a specific arena
and allows threads to use alternate arenas. We needed complete isolation of the one arena to see the efficiency gains noted above.</div>
<div><br>
</div>
<div>I also want to apologize to Jason. He's clearly spent a great deal of time optimizing the performance of jemalloc. Those of us operating in limited memory environments start off by disabling much of his hard work :)</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Jason Evans <<a href="mailto:jasone@canonware.com">jasone@canonware.com</a>><br>
<span style="font-weight:bold">Date: </span>Thursday, November 14, 2013 8:20 PM<br>
<span style="font-weight:bold">To: </span>Nikhil Bhatia <<a href="mailto:nbhatia@vmware.com">nbhatia@vmware.com</a>><br>
<span style="font-weight:bold">Cc: </span>"<a href="mailto:jemalloc-discuss@canonware.com">jemalloc-discuss@canonware.com</a>" <<a href="mailto:jemalloc-discuss@canonware.com">jemalloc-discuss@canonware.com</a>><br>
<span style="font-weight:bold">Subject: </span>Re: jemalloc tuning help<br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Calibri; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">You
can potentially mitigate the problem by reducing the number of arenas (only helps if per thread memory usage spikes are uncorrelated). Another possibility is to segregate short- and long-lived objects into different arenas, but this requires that you have
reliable (and ideally stable) knowledge of object lifetimes. In practice, segregation is usually very difficult to maintain. If you choose to go this direction, take a look at the "arenas.extend" mallctl (for creating an arena that contains long-lived objects),
and the ALLOCM_ARENA(a) macro argument to the [r]allocm() functions.</span></blockquote>
</span>
</body>
</html>