High amount of private clean data in smaps

[Jason Evans]

On Jun 27, 2013, at 8:31 PM, Thomas R Gissel wrote:
> I apologize for the delinquency of my response.  The previously provided stressTest.c does not exhibit the same RSS growth problem as our larger application.   As perhaps an interesting data point, running with 1 arena seems to eliminate or at least mitigate the issue to the point where it is no longer noticeable with our current tests. This seems to indicate internal, across arena, fragmentation, but what is still puzzling is that in the multi-arena configuration the jemalloc stats seem to disconfirm that hypothesis. Specifically, the pattern we see is that after our test has been running for some long period of time, usually several hours, and after our eviction logic has run several eviction cycles, the process begins to and continues to behave in the following way until the test is terminated: jemalloc's mapped statistic and process VmRSS seem to grow in a correlated way while jemalloc's active statistic stays flat.  Does this information give you any insights?  
> 
> 
I can only think of a couple of ways this could happen, barring an outright bug in jemalloc:

- madvise(2) is failing.  You should be able to use strace to determine whether this is an issue.  The only legitimate reason I can think of for this failure would be an interaction with mlockall(2).
- The application is touching memory that has been freed, after it has been purged via madvise(2).

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jemalloc.net/mailman/jemalloc-discuss/attachments/20130703/a6fb6afa/attachment.html>