How to make sure KDE has enough memory, and computer not freeze?

English Applications
1

I had a problem with KDE today

I was coding in IntelliJ IDEA, and started to run the application I coded.

Then the entire KDE freezed. I could not do anything.

For a short while I could move my mouse sluggish, but I could not do anything.
I could not even go out to the console CTRL+ALT+F2 So I could kill whatever whas freezing my desktop.
When I tried to enter tty console, then the entire KDE became frozen.

Nothing should be allowed to freeze the X,Window Manager that way.

I had no choice but to Kill my Computer forcefully but turning it off.

The only thing I know of that could freeze KDE that way is if there is no more free memory. It has happened to me before.

After I booted up again, I opened IntelliJ IDEA and executed the program I was coding, and it ran fine. So the problem is not there.

I know Java uses a lot of memory, both IntelliJ and the program I was running could be using a lot.
In addition I had 2 browsers open (Vivaldi, Chromium), Slack, Steam, Plex, Skype, Signal.
Many of these app are probably also a webapp, but I dont think they consume as much memory as a full fledge browser.

I have 32GB of memory. I am really considering upgrading to 64GB.

Is there any way to safeguard that X, KDE (Window Manager) always has enough memory to function?
At least it should warn me if the memory becomes over a certain threshold so that operation of X/KDE could be impacted.

2

Yes, had that experience as well, Linux is quite bad in handling low-memory situations in my opinion.

I know Linux has a Out Of Memory (OOM) manager but the times I did run in such a freeze I did not see any application being killed so it is, so I checked if this OOM is actually enabled?

Not sure it is:

$ sudo -s sysctl -a | grep oom
vm.oom_dump_tasks = 1
vm.oom_kill_allocating_task = 0
vm.panic_on_oom = 0

I was searching for vm.oom-kill, setting that to 1 should enable the OOM killer but I do not see it being present on my Tumbleweed machine…

3

I am no expert in Linux memory management, but I wonder if this problem can possibly be caused by insufficient swap.

4

This isn’t opinion but factual information:

No swap, no freeze. That is what I observe on infamous host erlangen. The OOM Killer readily does what it is supposed to do.

More:

"If memory is exhaustively used up by processes, to the extent which can possibly threaten the stability of the system, then the OOM killer comes into the picture.

NOTE: It is the task of the OOM Killer to continue killing processes until enough memory is freed for the smooth functioning of the rest of the process that the Kernel is attempting to run."

BTW: Its sibling freiburg works like a charm with 64GB an no swap: Freiburg first boot Tue 2023-05-09 09:50:48 CEST

5

Were you using the AI feature of that tool?

I can’t see anything at JetBrains which indicates which machines resources are needed by “IntelliJ IDEA” –

  • You could ask them for some indication of which machine resources are needed by that tool.
6

@DJViking I see this old issue https://youtrack.jetbrains.com/issue/IDEA-228324 and multiple hits with a search on “IntelliJ IDEA+ computer freezing”.

I suspect it’s an upstream issue…

7

No was not using the AI feature.

I don’t think the problem was IntelliJ IDEA itself.

I suspect (as it has happened to me before, and then not when using IntelliJ), that my system ran out of memory and thus KDE could not function.

8

I did some further research on OOM not doing its job and see earlyoom - The Early OOM Daemon:

The oom-killer generally has a bad reputation among Linux users. This may be part of the reason Linux invokes it only when it has absolutely no other choice. It will swap out the desktop environment, drop the whole page cache and empty every buffer before it will ultimately kill a process. At least that’s what I think that it will do. I have yet to be patient enough to wait for it, sitting in front of an unresponsive system.

earlyoom is available as package at least for Tumbleweed.

The is also hakavlad /nohang that has even more relevant documentation on it’s README.md

If you do not want to install additional software for this I found on this page:

For me setting vm.admin_reserve_kbytes=262144 does exactly this thing. OOM killer intervents before system goes completely unresponsive.

2 Likes
9

I did download and enable earlyoom:

$ sudo zypper install earlyoom
$ sudo systemctl enable earlyoom
$ sudo systemctl start earlyoom
$ sudo systemctl status earlyoom
â—Ź earlyoom.service - Early OOM Daemon
     Loaded: loaded (/usr/lib/systemd/system/earlyoom.service; enabled; preset: disabled)
     Active: active (running) since Wed 2023-08-30 22:04:55 CEST; 3s ago
       Docs: man:earlyoom(1)
             https://github.com/rfjakob/earlyoom
   Main PID: 7027 (earlyoom)
      Tasks: 1 (limit: 10)
        CPU: 11ms
     CGroup: /system.slice/earlyoom.service
             └─7027 /usr/bin/earlyoom -r 0 -m 6 -s 10 -n -p --avoid "(^|/)(systemd|Xorg|X|Xwayland|xdm|sddm|kdm|gdm|lightdm|plasmashell|kwin_wayland|kwin_x11|ssh|yast|yast2|y2controlcenter|zypper|rpm|dnf>

Aug 30 22:04:55  systemd[1]: Started Early OOM Daemon.
Aug 30 22:04:55  earlyoom[7027]: earlyoom 1.7
Aug 30 22:04:55  earlyoom[7027]: Notifying through D-Bus
Aug 30 22:04:55  earlyoom[7027]: Preferring to kill process names that match regex '(^|/)(java|Isolated Web Co|Web Content|WebExtensions|firefox|chrome|opera|falkon|ffmpeg|vlc|mpv|akregator|thumbna>
Aug 30 22:04:55  earlyoom[7027]: Will avoid killing process names that match regex '(^|/)(systemd|Xorg|X|Xwayland|xdm|sddm|kdm|gdm|lightdm|plasmashell|kwin_wayland|kwin_x11|ssh|yast|yast2|y2control>
Aug 30 22:04:55  earlyoom[7027]: Could not set priority: Permission denied. Continuing anyway
Aug 30 22:04:55  earlyoom[7027]: Could not set oom_score_adj: Permission denied. Continuing anyway
Aug 30 22:04:55  earlyoom[7027]: mem total: 31966 MiB, swap total:    0 MiB
Aug 30 22:04:55  earlyoom[7027]: sending SIGTERM when mem <=  6.00% and swap <= 10.00%,
Aug 30 22:04:55  earlyoom[7027]:         SIGKILL when mem <=  3.00% and swap <=  5.00%

Next to figure out why these “Permission denied”-s are there.

10

At the end of the day, isn’t that just masking the real issue of why the desktop environment is freezing?

I don’t use swap here, MicroOS has no swap, running kubernetes has no swap…

11

As you say you are running KDE, I had a similar issue caused by the fact that /tmp was full; among the stuff filling it up were a lot of plasma* folders. So I deleted everything that seemed to be superfluous and rebooted and the problem went away.

1 Like
12

See https://github.com/rfjakob/earlyoom/blob/master/MANPAGE.md#-p which is mentioned in #277.

1 Like
13

Thanks @ramdomPTM, that did the trick:

$ sudo systemctl edit earlyoom

[Service]
OOMScoreAdjust=-100
Nice=-20

$ sudo systemctl restart earlyoom

Now I do not see the “Permission denied” anymore.

For people wanting to see what happens on their machine when you are running out-of-memory (it will hang), try:

tail /dev/zero

14

Nope. Infamous host erlangen never minds:

erlangen:~ # journalctl -b -g oom -S 10:28 --no-pager 
Aug 31 10:28:12 erlangen kernel: pipewire-pulse invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=200
Aug 31 10:28:12 erlangen kernel:  oom_kill_process+0xf9/0x190
Aug 31 10:28:12 erlangen kernel: [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
Aug 31 10:28:12 erlangen kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole-c10de861bd434c6f904023674d0c6ca5.scope,task=tail,pid=9771,uid=0
Aug 31 10:28:12 erlangen kernel: Out of memory: Killed process 9771 (tail) total-vm:25025016kB, anon-rss:25021696kB, file-rss:896kB, shmem-rss:0kB, UID:0 pgtables:49008kB oom_score_adj:200
Aug 31 10:28:12 erlangen systemd[1087]: app-org.kde.konsole-c10de861bd434c6f904023674d0c6ca5.scope: A process of this unit has been killed by the OOM killer.
Aug 31 10:28:12 erlangen systemd[1087]: app-org.kde.konsole-c10de861bd434c6f904023674d0c6ca5.scope: Failed with result 'oom-kill'.
erlangen:~ #
15 
root@freiburg: ~
# journalctl -k -g oom
Aug 31 12:54:36 freiburg kernel: tail invoked oom-killer: gfp_mask=0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), order=0, oom_score_adj=0
Aug 31 12:54:36 freiburg kernel:  oom_kill_process+0xf9/0x190
Aug 31 12:54:36 freiburg kernel: [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
Aug 31 12:54:36 freiburg kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice,task=tail,pid=4099,uid=0
Aug 31 12:54:36 freiburg kernel: Out of memory: Killed process 4099 (tail) total-vm:63554948kB, anon-rss:63551488kB, file-rss:384kB, shmem-rss:0kB, UID:0 pgtables:124412kB oom_score_adj:0
Aug 31 12:54:38 freiburg kernel: oom_reaper: reaped process 4099 (tail), now anon-rss:88kB, file-rss:384kB, shmem-rss:0kB

root@freiburg: ~
#
16

Nice to see that at least in some cases the standard OOM manager kills the offending process.

Probably you did not have too many applications running when doing this test and thereby there was still enough memory available for the kernel to run the standard OOM manager. Like @DJViking I did run into the problem having several program open of which some have a large memory footprint.

17 
erlangen:~ # jobs
[1]+  Running                 stress-ng --vm 16 --vm-bytes 90% -t 1h &
erlangen:~ #

Free memory and cache are nearly exhausted:

karl@erlangen:~> free -h
               total        used        free      shared  buff/cache   available
Mem:            30Gi        30Gi       409Mi        92Mi       782Mi       705Mi
Swap:             0B          0B          0B
karl@erlangen:~>

System load:

karl@erlangen:~> w
 21:33:09 up 18 min,  1 user,  load average: 16,80, 12,09, 6,57
USER     TTY      VON              LOGIN@   IDLE   JCPU   PCPU WHAT
karl     tty2     :0               21:15   18:17  28.49 s  0.08 s /usr/bin/startplasma-x11
karl     pts/0    :0               21:15   18:02   0.00 s  0.98 s /usr/bin/kded5
karl     pts/1    :0               21:30   13.00 s  2.74 s  0.37 s /bin/bash
karl     pts/3    :0               21:33    3.00 s  0.40 s  0.00 s w
karl@erlangen:~>

Whenever memory is exhausted by running tail /dev/zero oom killer kicks in: http://www.mistelberger.net/oom-killer.journal

1 Like
18

Maybe things improved over time, I did not run into OOM events anymore after upgrading from 16 GB to 32 GB of RAM but as the experience of @DJViking shows not everything is fine yet.

19

Hello user,

I’d encountered freezing on KDE with OpenSUSE when use it first then made a research about it. Found some enhancements like removing some packages and adding flags to btrfs system.

For removing and locking packages:

akregator discover discover-backend-flatpak discover-backend-fwupd discover-backend-packagekit discover-lang kaddressbook kleopatra kmail knotes kontact korganizer patterns-kde-kde_pim

*note you ain’t use discover what software mangaer, for me it’s useless.

for
sudo nano /etc/fstab

 btrfs defaults,noatime,compress=zstd:3,space_cache,autodefrag,discard=async,commit=120                       0 0

hope this helps.

20

I did notice I had a lot of junk in /tmp.
However /tmp is on the root partition and has plenty of free space.
Although I did delete a lot from /tmp.

I just upgraded my Linux box from 32GB to 64GB memory. I guess that will also help. Although giving the PC more memory is a workaround, not a fix.