Desktop often freezes during CPU-intense tasks

I am using GNOME 45 (X11). Whenever the computer is running CPU-intense tasks (compiling, mostly), the desktop will probably freeze after some time. I cannot even use Ctrl+Alt+F2 etc to switch to other TYY. The freezing can be very long (~30min). My user can be automatically logged out from the GNOME shell, and my running task is then lost. The freezing does not happen if I am in text TTY.

What are the chances you’re actually swapping? Can you monitor system stats to get a better look on what’s happening?

How about journalctl --boot and dmesg after one of these freezes happens?

I don’t think I can monitor system stats because the whole system freezes, not just the desktop (so I cannot switch to text TTY or use another device to SSH onto it).

Yesterday when the freeze happens, it lasted for hours, so I just forced rebooting. The logs did not retain.

Specifically, how does the resource usage look like just before the system freezes up? The system freezing should make that easier if anything.

Either way, it sounds like swapping or hardware failure.

Note that while on Nixos the systemd-oomd service is enabled by default, the slices themselves are not configured to be under the control of the oom-deamon by default :

1 Like

@TLATER This is the resource usage:

I am taking a picture from text TTY.

See how your swap is nearly full? Linux will start using swap before you totally run out of memory, if your disk is slow that might cause these kinds of freezes. Consider reducing your swappiness to give the system more time before it starts heavily swapping.

Also check those values sorted by memory usage so you can have an eye on what is eating your memory.

Edit: Also, give bottom a shot over top, it gives a nicer picture of what’s been happening leading up to an issue.

Your swap is full. When it’s totally non-responsive, the system will be thrashing, evicting and reloading pages from executables, paging data in and out of swap, and so on, with everything blocking everything else from making progress.

Interestingly, you still have some free memory. That may mean that a large process (or several) recently exited, which isn’t entirely infeasible with all the compiler activity.

Two things to try:

  • add some more swap. Clearly, this build is pushing (at least) other idle pages out, and while it’s not thrashing now (cpus are all busy) perhaps more could leave more room for running gui desktop processes.
  • do you have /tmp on tmpfs? Perhaps move that to a real disk filesystem and reduce the memory and swap load, particularly from compiler and linker tempfiles.

Thank you two for your advice! I increased my swap to 32GB just now. I will see whether this will make it any better.