ZGC heap size and RSS counters
shade at redhat.com
Mon Dec 11 09:36:29 UTC 2017
On 12/11/2017 10:14 AM, Per Liden wrote:
> On 2017-12-11 09:55, Aleksey Shipilev wrote:
>> Hi there,
>> I'm trying ZGC on trivial workloads, and I have a question about footprint. The workload runs with
>> -Xms16g -Xms16g, but the RSS figures are at least 3x larger:
>> VmPeak: 18256721392 kB
>> VmSize: 18256721392 kB
>> VmLck: 0 kB
>> VmPin: 0 kB
>> VmHWM: 50729036 kB
>> VmRSS: 50729036 kB
>> RssAnon: 369700 kB
>> RssFile: 27688 kB
>> RssShmem: 50331648 kB
>> Is this because ZGC maps the same physical space with multiple virtual mappings? Or is it a bug?
> The kernel's RSS accounting is flaky at best, and varies depending on if you're using small or large
> pages (and it can also vary depending on which kernel version you're using).
> On Linux/x86_64, we map the heap in three different locations. When using small pages, you'll
> typically see that the same physical page will incorrectly be accounted for three times instead of
> once. On the other hand, when using large pages, you'll typically see a different behavior, as it's
> accounted to the hugetlbfs inode and not the process.
> In summary, it's not a bug in ZGC, but more a limitation in Linux's accounting.
Understood, that's what I thought. Do you think that is the problem in lieu of pervasive use of
containers that allocate/limit resources based on RSS?
More information about the zgc-dev