Fehlerhafte Container-Memory in cgroup2 mount

[Waishon]

Moin,

wir haben aktuell das Problem, dass einige Java-Anwendungen, die in einem Proxmox Container unter Ubuntu 24.04 laufen, einen Out-Of-Memory Error vom Linux-Kernel erhalten, bevor der Gargabe-Collector zugreifen kann.

Nach weiterer Analyse haben wir herausgefunden, dass Java nicht 1/4 des Memory-Limits des Containers als maxMemory verwendet, sondern 1/4 des Host-Memory. In unserem konkreten Fall hat der Host 128 GB RAM und der Container 4 GB RAM zugewiesen. Java denkt, es hat 32 GB zur Verfügung und füllt den RAM fleißig, bis der OOM-Killer bei 4 GB zuschlägt und die Anwendung crasht.

Die Limits können mit dem folgenden kleinen Programm angezeigt werden:

public class Main {
   // Ausgabe:
   // 30208
   // 2025
   // 2032
    public static void main(String[] args) {
        Runtime runtime = Runtime.getRuntime();
        System.out.println(runtime.maxMemory() / 1024 / 1024);
        System.out.println(runtime.freeMemory() / 1024 / 1024);
        System.out.println(runtime.totalMemory() / 1024 / 1024);
    }
}

Auch der folgende Java-Befehl zeigt keine Memory-Limits vom Provider: cgroupv2 an:

# java -XshowSettings:system -version
Operating System Metrics:
    Provider: cgroupv2
    Effective CPU Count: 2
    CPU Period: -1
    CPU Quota: -1
    CPU Shares: -1
    List of Processors: N/A
    List of Effective Processors: N/A
    List of Memory Nodes: N/A
    List of Available Memory Nodes: N/A
    Memory Limit: Unlimited
    Memory Soft Limit: 0.00K
    Memory & Swap Limit: Unlimited
    Maximum Processes Limit: 154442

openjdk version "21.0.3" 2024-04-16
OpenJDK Runtime Environment (build 21.0.3+9-Ubuntu-1ubuntu122.04.1)
OpenJDK 64-Bit Server VM (build 21.0.3+9-Ubuntu-1ubuntu122.04.1, mixed mode, sharing)

Die weitere Analyse zeigt, dass der Wert in memory.max im cgroup2-mount nicht korrekt befüllt ist:

# cat /sys/fs/cgroup/memory.max
max

Auf dem Host wird der memory.max für den LXC-Container aber korrekt befüllt

# cat /sys/fs/cgroup/lxc/117/memory.max 
4294967296

Zum Vergleich die Ausgabe von memory.max von podman unter Fedora 40. Hier zeigt Java auch die korrekten Memory-Limits an.

# podman run -m=1G -it debian:latest cat /sys/fs/cgroup/memory.max
1073741824

Handelt es sich hierbei um einen Bug in Proxmox/LXC, oder ist das expected-behaviour?
Version: pve-manager/8.2.4/faa83925c9641325 (running kernel: 6.8.8-1-pve)

 

[Falk R.]

Ich habe im Detail nicht so viel Ahnung davon, aber für mich klingt das nach normalem Verhalten.
Ein LXC Container ist ja eine eigenständige Laufzeitumgebung, sondern nur eine Abgekapselte Laufzeitumgebung des Host Kernels.
Wenn solche Werte beim Kernel abgefragt werden, kommt natürlich immer der RAM des Hosts raus. Man kann aus einem LXC noch viele andere Dinge des Hosts sehen, aber halt nur sehen (readonly)

 

[Waishon]

Hallo @Falk R.,

grundsätzlich hast du Recht, allerdings wurden dafür cgroups erfunden, um Prozesse in eine Gruppe zu Kapseln und dieser Ressourcen zuzuweisen. Damit die Prozesse wissen wie viel RAM in einer cgroup zur Verfügung stehen ist eine Möglichkeit die Abfrage von /sys/fs/cgroup/memory.max, die eigentlich den zugewiesenen RAM beinhalten soll (was bei Podman und Docker auch funktioniert). Hier scheint LXC allerdings "max" statt dem korrekten Wert einzutragen, wodurch Java 1/4 des Host Memories statt der zugewiesenen Resource nutzt. Das wirkt für mich wie ein Bug: siehe https://git.kernel.org/pub/scm/linu...Documentation/admin-guide/cgroup-v2.rst#n1278

 

[Falk R.]

Wird denn die cgroup oder der Kernel gefragt?