vm_memory_high_watermark.relative is not aware of cgroups limits of the container on Kubernetes

[luarx]

Describe the bug

Rabbitmq does not consider the container memory limit and it is using the total host memory

Reproduction steps

I run the container in a Kubernetes node with 16Gi
The container has configured a memory limit: 1000Mi

• Use rabbitmq:3 image (https://hub.docker.com/layers/library/rabbitmq/3/images/sha256-0707df9f526c8ff49b4484c5ef4c8799e86fe198428d65817dccbac6de74609e)
• Configure vm_memory_high_watermark.relative = 0.7

Expected behavior

I expect to see this watermark log:
Memory high watermark setting: 0.7 of available memory, computed to: 700 mi

Instead I see:
Memory high watermark setting: 0.7 of available memory, computed to: 11.4611 gb

Additional context

No response

[michaelklishin]

This is not a bug in RabbitMQ, and has been discussed many times before.

vm_memory_high_watermark.relative is not aware of anything Kubernetes-related. Its behavior completely depends on whether the runtime can determine the cgroups-capped value, and there are many factors that affect that, including the version of Kubernetes, the image OS, whether cgroups v2 are enabled, and so on.

Use vm_memory_high_watermark.absolute, which starting with 3.13.x even supports the same information unit suffixes as Kubernetes.

The list of Kubernetes-specific memory footprint and monitoring issues does not end there, in particular for clusters where streams and super streams are used.

[luarx]

Thanks for that useful information! It helps me a lot 🙌

[michaelklishin]

This doc guide is where vm_memory_high_watermark.absolute is covered.

I'll add a Kubernetes-specific note to both because this question keeps coming up.

[luarx]

Thanks you 🙌