I wanted to point at "pagetables:1452160kB" at the beginning of the OOM reports.
That is 1.4G of a 4GB system which seems non proportional.
Also "slab_unreclaimable:11360" on a 64k page size system is like 727MB
You might have more advanced trackers (use them then), but comparing the
same scenario with an older working and a new failing kernel and running
something like the following might see how that evolves after the
minutes of the run:
$ while /bin/true; do echo ""; date +%T; cat /proc/meminfo | grep -e
"PageT" -e "Slab" -e "SRecl" -e "SUnrecl"; sleep 3s; done
For the allocations that seem to go insane I'm unsure, I thought of
something like tracing them `sudo bpftrace -e
'tracepoint:kmem:mm_page_alloc { @[comm] = count(); }'` but in an
already overloaded system that will lose many events and your end
condition does not allow to evaluate the collected data - so that might
not be the best approach. The kernel folks will know better than me
anyway.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2143080
Title:
[Ubuntu 26.04] Running iperf3 client for longer duration causes OOM on
guest
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2143080/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
