0

How can I best debug the following issue from here on?

I have a

  • python application
  • running in a podman container which has
  • plenty disk I/O due to a numpy memmap of two huge files, one input file which I read in chunks, process the chunk and write the result in the other mem mapped file.

I noticed that running the application leads to

  • increasing total RAM usage, eventually leading to
  • OOM situations on my system.

I tried finding the cause but

  • couldn't find references in my python code which would leak memory.

According to sudo htop

  • the application itself does not consume the memory when accounting for resident memory size only, which it defines as text sections + data sections + stack usage.

  • Mem 11.0G / 14.6G

  • 18.7 MEM% (of ~16G RAM)

later:

  • Mem 14.3 / 14.6G
  • 0.1 MEM% (of ~16G RAM)

According to ps auwx:

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
user 9874 44.9 0.0 14651602572 8092 pts/0 DNsl+ 10:40 275:13 /root/.local/share/virtualenvs/app-4PlAip0Q/bin/python main.py 
# /proc/meminfo MemTotal: 15258424 kB MemFree: 143284 kB MemAvailable: 0 kB Buffers: 304 kB Cached: 51496 kB SwapCached: 1380 kB Active: 812 kB Inactive: 5800 kB Active(anon): 0 kB Inactive(anon): 1492 kB Active(file): 812 kB Inactive(file): 4308 kB Unevictable: 46068 kB Mlocked: 0 kB SwapTotal: 67108860 kB SwapFree: 66860540 kB Zswap: 0 kB Zswapped: 0 kB Dirty: 144 kB Writeback: 124 kB AnonPages: 1276 kB Mapped: 2916 kB Shmem: 46020 kB KReclaimable: 40196 kB Slab: 1482400 kB SReclaimable: 40196 kB SUnreclaim: 1442204 kB KernelStack: 3984 kB PageTables: 13424812 kB SecPageTables: 0 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 74737048 kB Committed_AS: 1396560 kB VmallocTotal: 34359738367 kB VmallocUsed: 54808 kB VmallocChunk: 0 kB Percpu: 2496 kB HardwareCorrupted: 0 kB AnonHugePages: 0 kB ShmemHugePages: 0 kB ShmemPmdMapped: 0 kB FileHugePages: 0 kB FilePmdMapped: 0 kB HugePages_Total: 1 HugePages_Free: 1 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB Hugetlb: 2048 kB DirectMap4k: 464816 kB DirectMap2M: 14129152 kB DirectMap1G: 2097152 kB

Screenshots

htop htop

Improve this question
2
  • The process is in a cgroup with /sys/fs/cgroup/ramlimit/memory.max set to 10737418240 (10G) which somehow has no effect. When I add cpu time constraints to the ramlimit group, that works though, so I assume I use the cgroupv2 correctly. Commented May 24, 2024 at 2:16
  • Initially I created the container with a memory limit but podman warned me about falling back to cgroupfs since I had no systemd session, maybe this interferes with the cgroup I set after the fact to try fix it. Commented May 24, 2024 at 2:18

1 Answer 1

Reset to default
0

Probably the page table entries fill up most of the RAM, using up ~13.4 GB, according to /proc/meminfo. I can't tell why memory mapping the files leads to this situation where apparently plenty of pages have to stay mapped and won't be flushed and discarded.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.