Red Hat Bugzilla – Bug 1288507
free shows used=0 inside OpenVZ containers
Last modified: 2017-12-01 21:08:32 EST
could you please backport following patch from mainline procps-ng git:
Description of problem:
under certain conditions free/top shows used=0 inside RHEL7-based OpenVZ containers.
total used free shared buff/cache available
Mem: 303104 0 7712 54956 295392 30936
Swap: 303104 215336 87768
This happen because OpenVZ kernel adjust /proc/meminfo output inside container,
Containers shares host memory effectively, but some memory-related parameters are not accounted per-container, therefore we cannot generate fully correct values and should use some heuristics to generate adequate meminfo output.
In some situations "Cached" value in meminfo output inside container is calculated as
cached = total - free - slab
btw we show Buffers = 0 inside containers.
Current procps version uses the same formula to calculate "used" value
used = total - free - buffers - cache - slab
As result "used" will be equal to 0 in such cases, and it confuses our customers.
We're going to minimize chances of described situation in our kernel,
however we would like to ask you to help us:
Following patch from mainline procps-ng git uses SlabReclaimable instead of current Slab
Updated procps-ng should not show "used=0" even in worst usecase.
We would ask you to include this patch in next update of procps-ng package.
Version-Release number of selected component (if applicable):
I'm unsure whether the above patch is a good solution. It distorts the reality and in the past we wanted to avoid things like that. It would require a discussion with the kernel team and a lot of thinking. It's non-trivial even when it looks so.
thank you for feedback.
We understand that described problem is OpenVZ specific,
and we'll try to avoid it in our (rhel6 and rhel7-based OpenVZ) kernels.
However we decided to notify you about this trouble too.
Please keep it in mind, and probably you'll fins some alternative solution.
Btw I was unable to reproduce described situation in our test lab,
it was observed on customers node only. However according to kernel sources described behaviour is not a bug, but expected behaviour for some configurations.