11

I've noticed lately that the performance of the UI in Gnome 3.36.2 seems to decay with uptime.

The most obvious manifestation is that over time, window animations have a delay and feel "sticky". Applications themselves seem unaffected. When I tell gnome to switch workspaces, there's about a half second to full second delay before the animation happens. This also applies to things like pressing the meta key to show all my windows or pressing alt-tab. Each one appears to share the same delay.

I'm running a fairly unremarkable desktop setup using vanilla gnome on Ubuntu 20.04.

My research on this issue seems to indicate that there were memory leak issues in 18.xx versions of the OS, but that those were supposedly fixed. The only thing I can conclude at this point is that a new issue has emerged, there was a regression, or the original fix didn't work.

The animation delay is sapping productivity to the point that I eventually have to reboot my system. The gnome-shell process definitely leaks over time as it starts around ~300mb and if left for a day will sit at ~600mb or more.


Regarding my overall hardware and nominal state of my system, I'm experiencing this issue even as I'm creating this question. I'm running the stock/vanilla gnome desktop, not the ubuntu customized one.

My system has 32gb of RAM, only 6gb of which are in use currently. My CPU usage fluctuates across 12 vcores up to 20% max. I have an RTX 2060 for my GPU.

At least as best as I can tell, I see no issue with the amount of resources gnome-shell is getting right now. 😉


Links


As requested by heynnema:

top - 08:52:58 up 16:18,  1 user,  load average: 0.75, 0.85, 0.77
Tasks: 494 total,   1 running, 491 sleeping,   0 stopped,   2 zombie
%Cpu(s):  2.9 us,  1.1 sy,  0.0 ni, 95.7 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 st
MiB Mem :  32029.7 total,  20316.2 free,   5763.1 used,   5950.4 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.  25355.6 avail Mem
ls -al ~/.local/share/gnome-shell/extensions
drwxrwxr-x 3 atrauzzi atrauzzi 4096 Apr 20 09:07 .
drwx------ 3 atrauzzi atrauzzi 4096 Jun  9 08:46 ..
ls -al /usr/share/gnome-shell/extensions
drwxr-xr-x 5 root root 4096 Apr  2 10:36 .
drwxr-xr-x 7 root root 4096 Jun  1 15:39 ..
drwxr-xr-x 2 root root 4096 Apr 19 20:24 desktop-icons@csoriano
drwxr-xr-x 3 root root 4096 Apr  2 10:36 [email protected]
drwxr-xr-x 3 root root 4096 May 30 10:18 [email protected]

(none of the above extensions are enabled as I'm running the vanilla gnome desktop, not the Ubuntu one)

sysctl vm.swappiness
vm.swappiness = 60
              total        used        free      shared  buff/cache   available
Mem:           31Gi       5.8Gi        19Gi       570Mi       6.3Gi        24Gi
Swap:         2.0Gi          0B       2.0Gi

  *-firmware                
       description: BIOS
       vendor: LENOVO
       physical id: 0
       version: BVCN11WW(V1.07)
       date: 07/04/2019
       size: 128KiB
       capacity: 10MiB
       capabilities: pci upgrade shadowing cdboot bootselect edd int13floppynec int13floppytoshiba int13floppy360 int13floppy1200 int13floppy720 int13floppy2880 int9keyboard int10video acpi usb biosbootspecification uefi
  *-cache:0
       description: L1 cache
       physical id: 5
       slot: L1 Cache
       size: 384KiB
       capacity: 384KiB
       capabilities: synchronous internal write-back unified
       configuration: level=1
  *-cache:1
       description: L2 cache
       physical id: 6
       slot: L2 Cache
       size: 1536KiB
       capacity: 1536KiB
       capabilities: synchronous internal write-back unified
       configuration: level=2
  *-cache:2
       description: L3 cache
       physical id: 7
       slot: L3 Cache
       size: 12MiB
       capacity: 12MiB
       capabilities: synchronous internal write-back unified
       configuration: level=3
  *-memory
       description: System Memory
       physical id: 25
       slot: System board or motherboard
       size: 32GiB
     *-bank:0
          description: SODIMM DDR4 Synchronous 2667 MHz (0.4 ns)
          product: KHX2666C15S4/16G
          vendor: Kingston
          physical id: 0
          serial: C2A812C5
          slot: ChannelA-DIMM0
          size: 16GiB
          width: 64 bits
          clock: 2667MHz (0.4ns)
     *-bank:1
          description: SODIMM DDR4 Synchronous 2667 MHz (0.4 ns)
          product: KHX2666C15S4/16G
          vendor: Kingston
          physical id: 1
          serial: C1A82704
          slot: ChannelB-DIMM0
          size: 16GiB
          width: 64 bits
          clock: 2667MHz (0.4ns)
  *-memory UNCLAIMED
       description: RAM memory
       product: Cannon Lake PCH Shared SRAM
       vendor: Intel Corporation
       physical id: 14.2
       bus info: pci@0000:00:14.2
       version: 10
       width: 64 bits
       clock: 33MHz (30.3ns)
       capabilities: pm bus_master cap_list
       configuration: latency=0
       resources: iomemory:400-3ff iomemory:400-3ff memory:4022210000-4022211fff memory:4022217000-4022217fff
sudo dmidecode -s bios-version
BVCN11WW(V1.07)

I don't believe my system is underpowered or in any way misconfigured such that this leak is as a result of my own doing.

8
  • 1
    I found this comment on a reddit thread where one poster suggests doing alt-f2 and running the command "r" in the run dialog to soft-reset gnome. That definitely fixes things, but of course, only for the problem to return after a while. Jun 9, 2020 at 13:07
  • It's a Lenovo Y740 from November 2019. Nvidia driver 440.64. I've no reason to suspect my memory being faulty. I think given that others are reporting the exact same issue (see reddit thread link above), even down to one person being able to suggest a non-permanent workaround to get performance back, I'm less inclined to blame any running processes on my system. Jun 9, 2020 at 14:52
  • Additionally, gnome-shell isn't taking up all my system memory. The problem is evidenced by a performance slowdown strictly in WM functionality long before I run into memory issues. My applications continue to perform at full speed, despite the WM slowdown. Jun 9, 2020 at 14:55
  • You forgot the last three commands for me, and the Lenovo Y740 has a bunch of variations, so I need the Lenovo Y740-what? part. I'm wanting to check the BIOS version with their web site.
    – heynnema
    Jun 9, 2020 at 16:50
  • 1
    Thanks for the info. It all looks good. But you forget to clarify exactly which Lenovo Y740-what? you have. I need that to check for BIOS updates.
    – heynnema
    Jun 9, 2020 at 18:59

3 Answers 3

8

I can confirm that I'm also experiencing the same memory leak with gnome-shell with a Ryzen 7 machine and Radion R9. After up-times approach roughly 2 days, I can visibly notice the lag the OP is experiencing. In addition, if I compare the memory of the process from the start, I will notice that it has climbed significantly and is still climbing.

A temporary workaround is ALT+F2+r, but really they should fix this. Especially if your working on a server which is left running all the time.

Edit: It seems like the memory leak is caused by gnome-shell animations and interactions. So if you do something like constantly minimise and maximise a window, or keep summoning and dismissing the activities view, you can see gnome-shell memory start to increase. It may appear to fluctuate for a while, but eventually the maximum amount of memory it uses will slowly rise and never fall.

2

I'm having the same problem; gnome-shell uses more and more memory. Slowing down animations and using up memory for nothing.

Since probably nobody will fix the error anyway, I implemented the following "fix" for myself:

Letting this script run every 15 minutes. When the memory usage of the gnome-shell process for the current user exceeds a usage percentage (limit) of 2% it will automatically restart the gnome-shell process (without loosing any work or applications, it's the same as running Alt+F2 and then R).

#!/bin/sh
    
logfile=/home/$(whoami)/bin/gnome-auto-restart.log
    
# memory limit of the gnome-shell-process as a percentage
limit="2.0"
    
restartShell() {
    export DISPLAY=:1
    busctl --user call org.gnome.Shell /org/gnome/Shell org.gnome.Shell Eval s 'Meta.restart("Restarting...")' > /dev/null 2>&1
}
    
mem=$(ps -o pid,user,%mem,command ax|grep -i /usr/bin/gnome-shell |grep -i $(whoami)|sort -b -k3 -r|head -n1|tr -s " "|cut -d" " -f3)
    
echo "$(date) checking memory usage percentage of gnome-shell ($mem) against $limit" >> $logfile
    
if awk 'BEGIN {exit !('$mem' >= '$limit')}'; then
    echo "$(date) --> limit reached, restarting gnome-shell" >> $logfile
    restartShell
else
    echo "$(date) --> limit not reached" >> $logfile
fi

I'm restarting the gnome-shell every night, too, as my workstation is running 24/7. And I'm thinking about restarting it at noon during lunch...

1
  • I have the same problem. Strangely it only started a few weeks ago, months after I installed 20.04. In your script I had to change -f3 to -f4 in the line starting with mem, don't know why. And there is no need to run the script every 15 minutes in my case.
    – newtothis
    Sep 6, 2021 at 2:55
0

I don't expect that this will fix your GNOME leaking memory, but it's important information anyway.

Lenovo Legion Y740-15IRHg (81UH0000US)

You have BIOS BVCN11WW (V1.07).

There's a newer BIOS available, BVCN12WW (V1.08), dated Jan 2, 2020, and can be downloaded here

Note: Make sure that I have the correct web page for your model #.

Note: Have good backups before updating the BIOS.

7
  • FWIW, I just looked up the firmware version and it seems like they dropped a bunch of performance (video down 10w!). Jun 10, 2020 at 0:43
  • @Omega Really? What is 10w!?
    – heynnema
    Jun 10, 2020 at 1:18
  • Ten watts? Could definitely be a performance hit, kind of weird if prior BIOS didn't add that penalty. Jun 10, 2020 at 12:58
  • @Omega How did you determine this performance hit? Just curious. You say "video down 10w!", but what does video have to do with ten watts?
    – heynnema
    Jun 10, 2020 at 14:31
  • I did a search for the BIOS version and there was at least one reddit thread with people talking about the changes. Jun 10, 2020 at 14:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .