Desktop often freezes during CPU-intense tasks

UlyssesZhan · March 16, 2024, 6:31am

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.

TLATER · March 16, 2024, 2:46pm

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?

UlyssesZhan · March 16, 2024, 7:00pm

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.

TLATER · March 16, 2024, 7:12pm

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.

MinerSebas · March 16, 2024, 11:09pm

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 :

github.com

NixOS/nixpkgs/blob/d691274a972b3165335d261cc4671335f5c67de9/nixos/modules/system/boot/systemd/oomd.nix#L10-L17


      
          options.systemd.oomd = {
            enable = lib.mkEnableOption (lib.mdDoc "the `systemd-oomd` OOM killer") // { default = true; };
          
          
  # Fedora enables the first and third option by default. See the 10-oomd-* files here:
            # https://src.fedoraproject.org/rpms/systemd/tree/806c95e1c70af18f81d499b24cd7acfa4c36ffd6
            enableRootSlice = lib.mkEnableOption (lib.mdDoc "oomd on the root slice (`-.slice`)");
            enableSystemSlice = lib.mkEnableOption (lib.mdDoc "oomd on the system slice (`system.slice`)");
            enableUserSlices = lib.mkEnableOption (lib.mdDoc "oomd on all user slices (`user@.slice`) and all user owned slices");

UlyssesZhan · March 21, 2024, 1:28am

@TLATER This is the resource usage:

I am taking a picture from text TTY.

TLATER · March 21, 2024, 2:09am

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.

uep · March 21, 2024, 2:11am

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.

UlyssesZhan · March 21, 2024, 4:04am

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