Public bug reported:
This is a place holder report, I will add more information as time
permits, mostly I want to see if this is recognised by others.
I have an Ubuntu 24.04 VM on 24.04 host, AMD 64, 64 GB. 20GB ram, 2GB
swap file. Used for development: runs docker compose and JetBrains IDE
mostly.
Problem. For the last couple of weeks, massive amounts of shared memory are
consumed. This leads to OOM and the kernel OOM killer activates usually killing
the gnome session. The systemd oomd does nothing and reports nothing in
journald.
The trigger to the shared memory use is elusive, but seems to be any kind of
activity, possibly terminal activity. Running docker compose will quickly
consume the 16 Gbi of free memory I have after boot (more or less), but so does
general use of the IDE. In typical use, I can get one to two hours before OOM
kill with the 20GBi allocated and 2GBi swap. I was using swapspace; the swap
file would grow to 8GBi but the kernel OOM kill came just the same.
Good news: kernel OOM kills are really decisive now :)
Observations:
* Problem is not reproducible with mainline 6.16.4 or 6.16.5 kernels. I have
been doing normal activity, and shared memory is < 1 GBi. By now with an ubuntu
kernel, it would be many GBi. (and thank goodness for this)
* Old versions of the IDE have the same problem. It is not a regression
in PyCharm. Also, it happens outside of the IDE.
* No diagnostic tool known to an LLM can find the process behind the shared
memory consumption. I have no actual proof of what is causing it. My suspicious
is writing output to terminals, but nothing I do could account for GBs (scroll
backlines were 10K now 1K, no difference)
* it is never handed back by closing any process or app. It is orphaned. It
continues to grow.
* it is a hard, kernel recognised memory allocation which the kernel can not
reclaim (until I log out). It causes swap exhaustion and then OOM killing,
every time.
* merely logging out releases all the shared memory. So it belongs to the user
and user cgroup slice, I guess.
* is the wayland gnome session
Initially huge pages were used for the guest, but in troubleshooting as
I removed them, the problem didn't change
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
This is a place holder report, I will add more information as time
permits, mostly I want to see if this is recognised by others.
I have an Ubuntu 24.04 VM on 24.04 host, AMD 64, 64 GB. 20GB ram, 2GB
swap file. Used for development: runs docker compose and JetBrains IDE
mostly.
- Problem. For the last couple of weeks, massive amounts of shared memory are
consumed. This leads to OOM and the kernel OOM killer activates usually killing
the gnome session. The systemd oomd does nothing and reports nothing in
journald.
- The trigger to the shared memory use is elusive, but seems to be any kind of
activity, possibly terminal activity. Running docker compose will quickly
consumer the 16 Gbi of free memory, but so does general use of the IDE. In
typical use, I can get one to two hours before OOM kil;.
+ Problem. For the last couple of weeks, massive amounts of shared memory are
consumed. This leads to OOM and the kernel OOM killer activates usually killing
the gnome session. The systemd oomd does nothing and reports nothing in
journald.
+ The trigger to the shared memory use is elusive, but seems to be any kind of
activity, possibly terminal activity. Running docker compose will quickly
consume the 16 Gbi of free memory, but so does general use of the IDE. In
typical use, I can get one to two hours before OOM kill with the 20GBi
allocated and 2GBi swap. I was using swapspace; the swap file would grow to
8GBi but the kernel OOM kill came just the same.
+ Good news: kernel OOM kills are really decisive now :)
Observations:
* Problem is not reproducible with mainline 6.16.4 or 6.16.5 kernels. I have
been doing normal activity, and shared memory is < 1 GBi. By now with an ubuntu
kernel, it would be many GBi. (and thank goodness for this)
* No diagnostic tool known to an LLM can find the process behind the shared
memory consumption. I have no actual proof of what is causing it. My suspicious
is writing output to terminals, but nothing I do could account for GBs (scroll
backlines were 10K now 1K, no difference)
* it is never handed back by closing any process or app. It is orphaned. It
continues to grow.
- * it is a hard, kernel recognised memory allocation which the kernel can not
reclaim (until I log out). It causes swap exhaustion and then OOM killing,
every time.
+ * it is a hard, kernel recognised memory allocation which the kernel can not
reclaim (until I log out). It causes swap exhaustion and then OOM killing,
every time.
- * merely logging out releases all the shared memory. So it belongs to the
user and user cgroup slice, I guess.
+ * merely logging out releases all the shared memory. So it belongs to the
user and user cgroup slice, I guess.
* is the wayland gnome session
-
-
- Initially huge pages were used for the guest, but in troubleshooting as I
removed them, the problem didn't change
+ Initially huge pages were used for the guest, but in troubleshooting as
+ I removed them, the problem didn't change
** Description changed:
This is a place holder report, I will add more information as time
permits, mostly I want to see if this is recognised by others.
I have an Ubuntu 24.04 VM on 24.04 host, AMD 64, 64 GB. 20GB ram, 2GB
swap file. Used for development: runs docker compose and JetBrains IDE
mostly.
Problem. For the last couple of weeks, massive amounts of shared memory are
consumed. This leads to OOM and the kernel OOM killer activates usually killing
the gnome session. The systemd oomd does nothing and reports nothing in
journald.
- The trigger to the shared memory use is elusive, but seems to be any kind of
activity, possibly terminal activity. Running docker compose will quickly
consume the 16 Gbi of free memory, but so does general use of the IDE. In
typical use, I can get one to two hours before OOM kill with the 20GBi
allocated and 2GBi swap. I was using swapspace; the swap file would grow to
8GBi but the kernel OOM kill came just the same.
- Good news: kernel OOM kills are really decisive now :)
+ The trigger to the shared memory use is elusive, but seems to be any kind of
activity, possibly terminal activity. Running docker compose will quickly
consume the 16 Gbi of free memory I have after boot (more or less), but so does
general use of the IDE. In typical use, I can get one to two hours before OOM
kill with the 20GBi allocated and 2GBi swap. I was using swapspace; the swap
file would grow to 8GBi but the kernel OOM kill came just the same.
+ Good news: kernel OOM kills are really decisive now :)
Observations:
* Problem is not reproducible with mainline 6.16.4 or 6.16.5 kernels. I have
been doing normal activity, and shared memory is < 1 GBi. By now with an ubuntu
kernel, it would be many GBi. (and thank goodness for this)
+
+ * Old versions of the IDE have the same problem. It is not a regression
+ in PyCharm. Also, it happens outside of the IDE.
* No diagnostic tool known to an LLM can find the process behind the shared
memory consumption. I have no actual proof of what is causing it. My suspicious
is writing output to terminals, but nothing I do could account for GBs (scroll
backlines were 10K now 1K, no difference)
* it is never handed back by closing any process or app. It is orphaned. It
continues to grow.
* it is a hard, kernel recognised memory allocation which the kernel can not
reclaim (until I log out). It causes swap exhaustion and then OOM killing,
every time.
* merely logging out releases all the shared memory. So it belongs to the
user and user cgroup slice, I guess.
* is the wayland gnome session
Initially huge pages were used for the guest, but in troubleshooting as
I removed them, the problem didn't change
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2122372
Title:
6.8 and 6.14 kernels massive shared memory bug
Status in linux package in Ubuntu:
New
Bug description:
This is a place holder report, I will add more information as time
permits, mostly I want to see if this is recognised by others.
I have an Ubuntu 24.04 VM on 24.04 host, AMD 64, 64 GB. 20GB ram, 2GB
swap file. Used for development: runs docker compose and JetBrains IDE
mostly.
Problem. For the last couple of weeks, massive amounts of shared memory are
consumed. This leads to OOM and the kernel OOM killer activates usually killing
the gnome session. The systemd oomd does nothing and reports nothing in
journald.
The trigger to the shared memory use is elusive, but seems to be any kind of
activity, possibly terminal activity. Running docker compose will quickly
consume the 16 Gbi of free memory I have after boot (more or less), but so does
general use of the IDE. In typical use, I can get one to two hours before OOM
kill with the 20GBi allocated and 2GBi swap. I was using swapspace; the swap
file would grow to 8GBi but the kernel OOM kill came just the same.
Good news: kernel OOM kills are really decisive now :)
Observations:
* Problem is not reproducible with mainline 6.16.4 or 6.16.5 kernels. I have
been doing normal activity, and shared memory is < 1 GBi. By now with an ubuntu
kernel, it would be many GBi. (and thank goodness for this)
* Old versions of the IDE have the same problem. It is not a
regression in PyCharm. Also, it happens outside of the IDE.
* No diagnostic tool known to an LLM can find the process behind the shared
memory consumption. I have no actual proof of what is causing it. My suspicious
is writing output to terminals, but nothing I do could account for GBs (scroll
backlines were 10K now 1K, no difference)
* it is never handed back by closing any process or app. It is orphaned. It
continues to grow.
* it is a hard, kernel recognised memory allocation which the kernel can not
reclaim (until I log out). It causes swap exhaustion and then OOM killing,
every time.
* merely logging out releases all the shared memory. So it belongs to the
user and user cgroup slice, I guess.
* is the wayland gnome session
Initially huge pages were used for the guest, but in troubleshooting
as I removed them, the problem didn't change
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2122372/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
