LXC RAM Verbrauch nicht nachvollziehbar

moxyproxy

New Member
Dec 7, 2020
5
0
1
40
Hallo liebe Proxmox Community!

Ich beobachte seit Längerem ein Problem mit LXCs bei Proxmox. Nach ein paar Tagen unterscheidet sich der Speicherverbrauch laut ps_mem (welches den Speicherverbrauch der einzelnen Prozesse in der VM addiert) und der zur Verfügung stehende Speicher laut free massiv.

Beispielsweise sehe ich in Datacenter -> [Proxmox Node name] -> Search in der Liste der ausgeführten virtuellen Maschinen die LXC #506 mit 94,1% Memory usage.

Free, innerhalb des LXC sagt:
Code:
# free
              total        used        free      shared  buff/cache   available
Mem:         524288      494012          28        1216       30248       30276
Swap:        524288      219292      304996

ps_mem, innerhalb des LXC sagt:
Code:
# ps_mem
 Private  +   Shared  =  RAM used       Program

  8.0 KiB +  18.0 KiB =  26.0 KiB       tee (2)
  4.0 KiB +  29.5 KiB =  33.5 KiB       vsftpd
  8.0 KiB +  32.0 KiB =  40.0 KiB       sh (2)
 12.0 KiB +  36.0 KiB =  48.0 KiB       agetty (3)
  4.0 KiB +  85.5 KiB =  89.5 KiB       qmgr
 48.0 KiB +  44.5 KiB =  92.5 KiB       crond
  4.0 KiB +  89.5 KiB =  93.5 KiB       tlsmgr
  4.0 KiB + 103.5 KiB = 107.5 KiB       su
  4.0 KiB + 107.0 KiB = 111.0 KiB       sudo
 16.0 KiB + 177.0 KiB = 193.0 KiB       logger (4)
 88.0 KiB + 115.5 KiB = 203.5 KiB       varnishd
 88.0 KiB + 143.5 KiB = 231.5 KiB       pickup
112.0 KiB + 129.5 KiB = 241.5 KiB       master
172.0 KiB +  81.0 KiB = 253.0 KiB       bacula-fd
  8.0 KiB + 259.0 KiB = 267.0 KiB       (sd-pam) (2)
188.0 KiB + 330.0 KiB = 518.0 KiB       sshd (3)
504.0 KiB +  31.5 KiB = 535.5 KiB       redis-server
376.0 KiB + 231.0 KiB = 607.0 KiB       systemd-journald
632.0 KiB + 130.0 KiB = 762.0 KiB       bash (3)
640.0 KiB + 131.0 KiB = 771.0 KiB       rsyslogd
444.0 KiB + 377.0 KiB = 821.0 KiB       cache-main
792.0 KiB + 111.0 KiB = 903.0 KiB       dbus-daemon
144.0 KiB + 805.0 KiB = 949.0 KiB       php-fpm (3)
836.0 KiB + 160.5 KiB = 996.5 KiB       NetworkManager
660.0 KiB + 347.5 KiB =   1.0 MiB       systemd-logind
  1.6 MiB + 532.5 KiB =   2.1 MiB       systemd (3)
344.0 KiB +   2.0 MiB =   2.3 MiB       httpd (6)
---------------------------------
                         14.1 MiB
=================================

Hat jemand eine Idee, woran das liegen könnte, wohin der fehlende Speicher verschwunden ist, wie ich die Sache weiter debuggen kann oder sogar einen Lösungsvorschlag? Hat das Problem einen Namen, oder kann es vielleicht sogar per Konfiguration gelöst werden?

Ich verwende PVE 6.3-2 auf Debian Stretch. Der Kernel ist "5.4.78-1-pve #1 SMP PVE 5.4.78-1 (Mon, 30 Nov 2020 10:57:47 +0100) x86_64 GNU/Linux"

In der LXC läuft
CentOS Linux release 8.1.1911 (Core)

Filesystem ist mdadm auf 2 NVMe Speichern (Raid 1), darauf LVM thin pool, darin lvg pro LXC.

Das LXC läuft mit 512 MB RAM und 512 MB SWAP.

Für jede Hilfe bin ich dankbar!
 

moxyproxy

New Member
Dec 7, 2020
5
0
1
40
Was vielleicht noch relevant sein könnte: es handelt sich um unprivileged Container.
Das Problem (immer mehr/weniger RAM verbraucht laut free/ps_mem) tritt bei nicht allen CTs gleich schnell auf, obwohl alle mit dem selben CentOS Image laufen. Die stärker betroffenen CTs müssen nach 3-5 Tagen neu gestartet werden, damit keine Prozesse abstürzen. Ein paar der CTs haben auch eine Uptime von 120 Tagen erreicht gehabt. Alle stark betroffenen CTs haben Apache, Varnish und PHP-FPM im Einsatz. Die weniger stark betroffenen CTs betreiben ein Logging-Daemon, oder einen Bacula (Backup) Service, oder eine MariaDB Instanz.

Kann ich noch Informationen liefern, die besseren Einblick liefern?

Hat jemand ein vergleichbares Problem beobachtet?
 

fabian

Proxmox Staff Member
Staff member
Jan 7, 2016
7,483
1,395
164
tmpfs verbrauch im container? ansonsten anderer memory verbrauch im kernel, der der container cgroup zugeordnet wird..
 

moxyproxy

New Member
Dec 7, 2020
5
0
1
40
Danke für die rasche Antwort!

tmpfs dürfte ein Thema gewesen sein, da war tatsächlich in /run von journald ~250 MB belegt, welches ich geleert und per Config in der LXC limitiert habe. Das erklärt das Problem in dem Fall zu 25-30%.

Nach dem Reboot sind wir bei tmpfs-Nutzung von ~10 MB insgesamt, ps_mem sagt 102 MB, free -m sagt "324 [mb] used".

Lässt sich "memory verbrauch im kernel, der der container cgroup zugeordnet wird" irgendwie einsehen oder debuggen? Ein Hinweis auf eine Doku diesbezüglich sollte auch helfen.

/sys/fs/cgroup/memory/lxc/<vmid>/ns scheint es nicht zu sein, da sich die Werte dort nicht mit den IDs der LXCs unterscheiden (und dass alle LXCs genau die selben Werte des Speicherverbrauches haben, wäre sehr überraschend).
 

fabian

Proxmox Staff Member
Staff member
Jan 7, 2016
7,483
1,395
164
/proc/meminfo im container gibt eventuell aufschluss (einige der felder werden hier von lxcfs mit den werten aus den cgroups überschrieben, aber nicht alle..)
 

moxyproxy

New Member
Dec 7, 2020
5
0
1
40
/proc/meminfo in der VM sagt mir leider nichts Aufschlussreiches - vergleiche ich die Werte zwischen stark und weniger stark betroffenen LXCs, ergibt sich kein Muster.

Auffällig ist aber (danke für die Anregung mit /proc/meminfo aus dem Container) der Inhalt von /sys/fs/cgroup/memory/* aus dem Container.

Code:
# for STAT in $(ls -1f /sys/fs/cgroup/memory/ | grep in_bytes); do echo "/sys/fs/cgroup/memory/$STAT in MB:"; expr $(cat "/sys/fs/cgroup/memory/$STAT") / 1024 / 1024; done
/sys/fs/cgroup/memory/memory.kmem.tcp.usage_in_bytes in MB:
0
/sys/fs/cgroup/memory/memory.soft_limit_in_bytes in MB:
8796093022207
/sys/fs/cgroup/memory/memory.kmem.tcp.max_usage_in_bytes in MB:
0
/sys/fs/cgroup/memory/memory.max_usage_in_bytes in MB:
768
/sys/fs/cgroup/memory/memory.limit_in_bytes in MB:
8796093022207
/sys/fs/cgroup/memory/memory.memsw.max_usage_in_bytes in MB:
1003
/sys/fs/cgroup/memory/memory.kmem.max_usage_in_bytes in MB:
762
/sys/fs/cgroup/memory/memory.usage_in_bytes in MB:
767
/sys/fs/cgroup/memory/memory.memsw.limit_in_bytes in MB:
8796093022207
/sys/fs/cgroup/memory/memory.kmem.limit_in_bytes in MB:
8796093022207
/sys/fs/cgroup/memory/memory.memsw.usage_in_bytes in MB:
919
/sys/fs/cgroup/memory/memory.kmem.usage_in_bytes in MB:
757
/sys/fs/cgroup/memory/memory.kmem.tcp.limit_in_bytes in MB:
8796093022207
# free -m
              total        used        free      shared  buff/cache   available
Mem: 768 751 0 1 16 16
Swap: 512 152 359

memory.kmem_usage_in_bytes in Höhe von etwa 757 MB klingt für das Problem sehr plausibel.
Hat jemand eine Idee, wie ich da weiter eingrenzen und die Ursache finden könnte?
Könnte es an der Verwendung von CentOS selbst im LXC liegen?
 

fabian

Proxmox Staff Member
Staff member
Jan 7, 2016
7,483
1,395
164
https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt

Code:
2.7.1 Current Kernel Memory resources accounted

* stack pages: every process consumes some stack pages. By accounting into
kernel memory, we prevent new processes from being created when the kernel
memory usage is too high.

* slab pages: pages allocated by the SLAB or SLUB allocator are tracked. A copy
of each kmem_cache is created every time the cache is touched by the first time
from inside the memcg. The creation is done lazily, so some objects can still be
skipped while the cache is being created. All objects in a slab page should
belong to the same memcg. This only fails to hold when a task is migrated to a
different memcg during the page allocation by the cache.

* sockets memory pressure: some sockets protocols have memory pressure
thresholds. The Memory Controller allows them to be controlled individually
per cgroup, instead of globally.

* tcp memory pressure: sockets memory pressure for the tcp protocol.

memory.stat in der cgroup ist vielleicht auch noch spannend.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get your own in 60 seconds.

Buy now!