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
_______________________________________________
jemalloc-discuss mailing list
[email protected]
http://www.canonware.com/mailman/listinfo/jemalloc-discuss
