High CPU usage by gnome-shell when only running gnome-terminal

[Pedro Côrte-Real]

Even when doing nothing but displaying a terminal screen with top running gnome-shell uses 10% of a CPU. That seems excessive. I disabled all extensions to try and make the test fair. Enabling the system monitor extension increases the load to 13-14%. It seems that the gnome-shell screen painting is highly CPU consuming even if screen updates are infrequent (1 a second for all these cases).

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: gnome-shell 3.28.1-0ubuntu2
ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
Uname: Linux 4.15.0-20-generic x86_64
ApportVersion: 2.20.9-0ubuntu7
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue May 29 11:38:05 2018
DisplayManager: gdm3
InstallationDate: Installed on 2016-10-27 (578 days ago)
InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719)
SourcePackage: gnome-shell
UpgradeStatus: Upgraded to bionic on 2018-05-19 (9 days ago)

[Daniel van Vugt (vanvugt)]

What screen resolution are you using?

You can just run 'xrandr' and send us the output.

[Daniel van Vugt (vanvugt)]

Also, is the terminal window touching the launcher to the left? Is it maximized? Or does the problem persist when the terminal is a small window in the middle of the screen?

[Pedro Côrte-Real (pedrocr)]

The resolution is 2560x1440. I was testing with the terminal window maximized but the outcome is the same when the terminal is just a small window in the middle. The CPU usage is roughly half when the computer is charging, probably because the CPU is throttled up.

[Pedro Côrte-Real (pedrocr)]

For reference, logging in with Unity on the same hardware compiz uses about 1% or less CPU. So gnome-shell seems to be using 10x the CPU on this hardware at least. This was an upgraded install from 16.04 and I'll be trying a clean reinstall instead.

[Daniel van Vugt (vanvugt)]

Yeah, I know. I'm building a list of issues here: https://trello.com/c/pe5mRmx7

Do you find the problem is better in Gnome Shell on Xorg, compared to Gnome Shell on Wayland?

[Pedro Côrte-Real (pedrocr)]

Just tested this on Wayland and the situation seems slightly better. The same test (just the terminal, no extensions) is about 2-3% of CPU usage (compares with less than 1% for compiz) and when I turn on extensions (particularly system monitor) it goes to 5-7%. Not great but better.

Great work on that list of issues. I don't mean just speed I've also found a bunch of other polish issues like the scaling. I'm just surprised gnome-shell is still this rough after so many years of development.

[Pedro Côrte-Real (pedrocr)]

Did a clean install and here are the numbers with a Xorg session:

- all default: less than 1% (comparable or even better to compiz)
- turning on seconds on the top bar clock: around 3%
- turning on extensions (particularly system monitor): 6-9%

So it seems gnome-shell is perfectly capable of using low CPU but it's very easy to make it use a lot more CPU by adding things that only do one update a second (both the clock and system monitor are like that).

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mike Pontillo (mpontillo)]

I'm seeing moderately high CPU usage from the gnome-shell process as well. It seems to stay running at at least 5% at all times. I decided to use strace to see what it was doing:

$ sudo strace -c -p 6916
strace: Process 6916 attached
strace: Process 6916 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
 25.38 0.054330 6 9277 8116 recvmsg
 21.45 0.045927 10 4454 ioctl
 18.90 0.040462 12 3295 poll
 11.95 0.025583 24 1045 24 futex
  7.23 0.015478 11 1388 writev
  4.05 0.008663 7 1302 write
  2.82 0.006048 4 1500 getpid
  2.14 0.004579 5 914 mprotect
  2.07 0.004431 7 657 read
  1.11 0.002372 11 212 timerfd_create
  0.94 0.002012 8 251 close
  0.87 0.001859 9 212 timerfd_settime
  0.40 0.000857 22 39 openat
  0.20 0.000437 6 78 fstat
  0.19 0.000413 3 120 getrusage
  0.11 0.000244 7 36 mmap
  0.10 0.000209 5 39 fcntl
  0.06 0.000129 129 1 restart_syscall
  0.02 0.000037 37 1 munmap
  0.01 0.000029 7 4 1 recvfrom
  0.00 0.000000 0 70 60 stat
------ ----------- ----------- --------- --------- ----------------
100.00 0.214099 24895 8201 total

The strange thing here is the large number of EAGAIN errors from the recvmsg() syscall. When I run strace without the -c I see output such as:

recvmsg(12, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(12, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(5, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(12, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(12, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)

[Scott Grant (srgrant)]

I'm finding the same symptoms from gnome-shell, relatively high cpu use by gnome-shell with all extenstions deisabled (if I turn on extensions the cpu usages is ridiculous high, in the range of 20-50%).
I checked strace as above and am finding the same high number of errors from the recvmsg call:

strace: Process 1321 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
 39.28 1.151799 7 168623 145929 recvmsg
 24.30 0.712624 14 52590 poll
 12.08 0.354380 9 41109 ioctl
  8.01 0.234871 12 18865 writev
  6.37 0.186740 7 26188 write
  4.18 0.122557 5 23811 getpid
  2.65 0.077663 7 11653 read
  1.26 0.036853 5 7852 mprotect

[OkropNick (okropnick)]

10 seconds of strace on core i5

strace -c -p 17477
strace: Process 17477 attached
^Cstrace: Process 17477 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
 64.24 0.445795 2 258405 clock_gettime
 16.78 0.116422 4158 28 3 clone
  4.95 0.034359 32 1060 ioctl
  4.00 0.027777 3 9464 8685 recvmsg
  2.93 0.020340 6 3293 poll
  1.62 0.011226 2 5567 getpid
  1.49 0.010356 2 5605 sched_yield
  1.35 0.009360 5 1755 43 futex
  0.84 0.005839 4 1333 writev
  0.71 0.004905 2 2817 mprotect
  0.41 0.002868 3 999 write
  0.38 0.002657 3 982 read
  0.08 0.000527 9 62 4 openat
  0.06 0.000408 4 92 nanosleep
  0.05 0.000335 3 110 close
  0.03 0.000237 2 112 fstat
  0.03 0.000198 3 61 mmap
  0.02 0.000112 2 54 fcntl
  0.01 0.000083 83 1 restart_syscall
  0.01 0.000059 2 28 pipe2
  0.01 0.000050 2 22 getrusage
  0.00 0.000017 3 6 wait4
  0.00 0.000016 1 12 12 lseek
  0.00 0.000006 2 4 rt_sigreturn
  0.00 0.000003 1 4 statfs
------ ----------- ----------- --------- --------- ----------------
100.00 0.693955 291876 8747 total

[Daniel van Vugt (vanvugt)]

Thanks for reminding me about this bug. It's now on this checklist:

https://trello.com/c/pe5mRmx7

[Stephan Sturges (stephan-st)]

Same problem here, running Ubuntu 18.04 on a Dell XP 9570 with a screen resolution of 3840x2160.

I am also seeing a lot of errors in recvmsg:

strace: Process 1312 attached
^Cstrace: Process 1312 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
 75.95 0.065664 2 26665 clock_gettime
  8.38 0.007247 6 1238 1125 recvmsg
  4.08 0.003530 9 410 poll
  3.18 0.002747 3 802 getpid
  2.09 0.001808 10 189 writev
  1.81 0.001566 11 140 124 stat
  1.21 0.001048 7 142 1 futex
  1.15 0.000997 2 510 sched_yield
  0.79 0.000686 4 162 write
  0.66 0.000568 4 132 read
  0.40 0.000348 3 106 mprotect
  0.12 0.000106 8 13 nanosleep
  0.06 0.000051 6 9 mmap
  0.04 0.000034 11 3 openat
  0.03 0.000023 4 6 fstat
  0.02 0.000014 5 3 close
  0.01 0.000010 3 3 fcntl
  0.01 0.000009 1 8 getrusage
  0.00 0.000000 0 1 restart_syscall
------ ----------- ----------- --------- --------- ----------------
100.00 0.086456 30542 1250 total

[Gustav Bylund (maistho)]

gnome-shell idling at around 17% usage right now, here's an strace for around 15 seconds:

strace: Process 963 attached
^Cstrace: Process 963 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
 28,65 0,167283 0 242195 173541 recvmsg
 21,44 0,125202 0 161286 poll
 19,44 0,113499 7 15141 274 futex
 10,32 0,060288 2 28487 ioctl
 10,01 0,058442 1 55063 writev
  2,89 0,016898 0 24103 getpid
  0,93 0,005429 1 3620 mmap
  0,90 0,005257 0 7155 close
  0,90 0,005229 1 3553 memfd_create
  0,87 0,005066 1 3571 munmap
  0,83 0,004830 0 7112 lseek
  0,77 0,004507 1 3553 sendmsg
  0,59 0,003440 0 3554 recvfrom
  0,58 0,003374 0 3553 ftruncate
  0,43 0,002504 0 3334 mprotect
  0,27 0,001554 0 1932 write
  0,16 0,000936 0 1107 read
  0,02 0,000115 1 61 12 openat
  0,01 0,000030 0 92 fstat
  0,00 0,000018 0 43 fcntl
  0,00 0,000004 0 6 getrusage
  0,00 0,000004 4 1 restart_syscall
------ ----------- ----------- --------- --------- ----------------
100.00 0,583909 568522 173827 total

[Daniel van Vugt (vanvugt)]

Gustuv:

Please open a new bug for the issue you describe, by running:

  ubuntu-bug gnome-shell

If gnome-shell is idling with that much CPU usage then it's usually an extension to blame.

[Daniel van Vugt (vanvugt)]

Pedro,

I can't seem to find any significant CPU usage by gnome-shell when the terminal is busy, using Ubuntu 18.10.

Can you please try live booting 18.10 and tell us if you find that is better now?
http://releases.ubuntu.com/18.10/ubuntu-18.10-desktop-amd64.iso

[Daniel van Vugt (vanvugt)]

Also,

Everyone please REMOVE or DISABLE all your extensions before measuring the CPU usage of gnome-shell. We are not interested in the performance problems introduced by extensions here.

[dimjava (dimjava)]

Tried on both 18.04 (gnome-shell version 3.28.3 and 3.28.1) and 18.10 (3.30.1).
No extensions at all.

Got cpu usage changing from 20% to 90% just moving mouse around.

3.28.1 behaviour is slightly better: from 15% to 30-40%

[Daniel van Vugt (vanvugt)]

Moving the mouse around is https://gitlab.gnome.org/GNOME/mutter/issues/283, not this one. Feel free to open a new Launchpad bug for it.

This bug is about when only gnome-terminal is running without any interaction. Not moving the mouse.

[Nate Byrnes (b-nate)]

I've noticed the same issue with all extensions disabled. It seems very correlated with changes on the screen, to include moving the mouse. I've watched 'top' over an SSH connection to the system running gnome. If I have just a terminal window open any updates in that window cause gnome-shell CPU to jump to 7-9% CPU for a couple seconds (according to top which is updating every second on a remote shell). The updates and activities I've tested so far that seem to show this behavior are:

- moving the mouse around on the screen

- typing any amount of text in the open terminal window

- having top running in the open terminal window.

I'm guessing there is something in gnome-shell copying the screen to a buffer, and, after some period of inactivity it decreases its rate of copying... perhaps?

[Daniel van Vugt (vanvugt)]

Yes this bug is about buffer copies really, and so the performance of software-rendered toolkits like GTK.

Please be careful to not discuss moving the mouse in this bug because that's a different problem. Please open a new bug for mouse movements and mention https://gitlab.gnome.org/GNOME/mutter/issues/283

[Pat Trainor (holesflow)]

I see 9% consistently, and as with those above, clock_gettime seems to be the culprit:

pat@wopr:~$ sudo strace -c -p 29333
[sudo] password for pat:
strace: Process 29333 attached

^Cstrace: Process 29333 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
 83.37 2.716542 2 1494072 clock_gettime
  3.62 0.117823 32 3654 ioctl
  3.40 0.110891 3 40996 36714 recvmsg
  2.53 0.082418 6 13709 poll
[...]

Ubuntu 18.04, i7 4.0GHZ, 32GB RAM uname -a:
Linux wopr 4.15.0-42-generic #45-Ubuntu SMP Thu Nov 15 19:32:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

[Pat Trainor (holesflow)]

In case the video is still suspected:

pat@wopr:~$ xrandr
Screen 0: minimum 8 x 8, current 9600 x 2160, maximum 16384 x 16384
VGA-0 disconnected (normal left inverted right x axis y axis)
LVDS-0 disconnected (normal left inverted right x axis y axis)
HDMI-0 disconnected (normal left inverted right x axis y axis)
DP-0 connected primary 1920x1080+3840+1080 (normal left inverted right x axis y axis) 344mm x 194mm
   1920x1080 60.02*+ 47.99
DP-1 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 600mm x 340mm
   3840x2160 60.00*+ 30.00
   2560x1440 59.95
   1920x1080 60.00 59.94
   1600x900 60.00
   1280x1024 60.02
   1280x800 59.81
   1280x720 60.00 59.94
   1152x864 59.96
   1024x768 60.00
   800x600 60.32
   720x480 59.94
   640x480 59.94 59.93
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 connected 3840x2160+5760+0 (normal left inverted right x axis y axis) 600mm x 340mm
   3840x2160 60.00 + 30.00*
   2560x1440 59.95
   1920x1080 60.00 59.94
   1600x900 60.00
   1280x1024 60.02
   1280x800 59.81
   1280x720 60.00 59.94
   1152x864 59.96
   1024x768 60.00
   800x600 60.32
   720x480 59.94
   640x480 59.94 59.93
DP-4 disconnected (normal left inverted right x axis y axis)

[Daniel van Vugt (vanvugt)]

Regarding:

% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
 83.37 2.716542 2 1494072 clock_gettime

I believe that's 83.37% of the process' system time. It's not the overall CPU usage of the function. If you use the 'time' command or compare fields 14 and 15 in /proc/PID/stat then you will likely find the process' system time is not a significant percentage of its overall time used. Because that doesn't include the 'user' time which is a much bigger fraction. So the above is 83.37% of a small fraction and should be ignored.

Basically it means 'strace -c' is meaningless to regular users and should be ignored.

[Daniel van Vugt (vanvugt)]

Actually... my gnome-shell seems to spend about 25% of its time in the kernel ("system time"), and 75% in user space. That means 0.25*0.8327 --> around 20% of gnome-shell's time is spent inside the clock_gettime system call. This is quite significant actually. Thanks.

[Nicolas Göddel (ngoeddel)]

After years of high CPU usage with gnome-shell and not finding the issue, I finally found this bug report, disable showing the seconds of the clock in the top panel and now the CPU usage is between 0-1% instead of 40% and more. What the heck? Thank you!

Still clock_gettime is active 71% of the time but the overall usage is no minimal. Maybe my battery will last longer now.

[Mark Preston (emarkpreston)]

I disabled all extensions in Firefox. I'm trying to fix my high CPU. I'm not a computer adept.

mark@Lexington:~$ ps aux | grep 'Z'
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 2587 0.0 0.0 0 0 ? Z 08:05 0:00 [apccontrol] <defunct>
mark 2608 0.0 0.0 0 0 tty2 Z+ 08:05 0:00 [livepatch-notif] <defunct>
mark 19191 0.0 0.0 0 0 tty2 Z+ 16:38 0:00 [livepatch-notif] <defunct>

mark@Lexington:~$ pstree -p -s 2608
systemd(1)───gdm3(1052)───gdm-session-wor(2026)───gdm-x-session(2053)───gnome-s+

mark@Lexington:~$ pstree -p -s 19191
systemd(1)───gdm3(1052)───gdm-session-wor(2026)───gdm-x-session(2053)───gnome-session-b(2065)───update-notifier(2599)───livepatch-not+

Before installing 18.04 my CPU load averages ranged from .5 to 1-ish. Now they are always over 2. That's not a heat issues, obvs, but it is making for erratic mouse/screen appearances.

mark@Lexington:~$ canonical-livepatch status --verbose
client-version: 8.1.0
machine-id: 6ac6b179c17c458d850424626c8b8c04
machine-token: be21448785bf432db941d268ec4e9032
architecture: x86_64
cpu-model: AMD FX(tm)-6300 Six-Core Processor
last-check: 2019-01-04T17:08:29.620560634-08:00
boot-time: 2019-01-04T08:03:53-08:00
uptime: 9h5m24s
status:
- kernel: 4.15.0-43.46-generic
  running: true
  livepatch:
    checkState: checked
    patchState: nothing-to-apply
    version: ""
    fixes: ""

Sources:

http://ubuntu.5.x6.nabble.com/On-restart-Livepatch-Notif-is-always-a-zombie-process-td5176526.html

[Roland (Rolandixor) Taylor (rolandixor)]

I really hope this is fixed by 19.04

[Daniel van Vugt (vanvugt)]

Pedro, please answer comment #18. I would like to know if 18.10 or 19.04 has changed the situation for you.

---

Nicolas, this bug is not about showing seconds in the clock. Please comment in bug 1814125 instead for that issue and not here. Or log a new bug.

---

Mark, this bug is about the CPU usage of the gnome-shell process only, when displaying a terminal and nothing else. If you experience any other problem then please open a new bug.

---

Roland, there is insufficient information in this bug at the moment and some irrelevant comments. So no, nobody is working on it because we're not sure any bug exists. Also be careful to remember that this bug is about the CPU usage of the gnome-shell process only when displaying a terminal and nothing else. If you experience any other problem then please open a new bug.

[Pedro Côrte-Real (pedrocr)]

Hi Daniel. I can't even reproduce it in 18.04 anymore. I tried:

- Booting 18.04.2 from a usb disk
- The 18.04 GNOME Wayland session (what I'm trying now to avoid a bunch of other bugs)
- The 18.04 default Ubuntu Xorg session

all of them seem to be showing reasonable <1% gnome-shell CPU usage when showing just a gnome-terminal running top. Don't know what fixed it but it does seem fixed. I can live boot 18.10 if that's useful or even 19.04 if there are images for that already somewhere.

[Daniel van Vugt (vanvugt)]

Pedro,

That's enough for me, thanks.

This bug is now closed. If anyone experiences any more issues at all then please open a new bug by running:

  ubuntu-bug gnome-shell

And if anyone did want to test 19.04 then you can find it here:

  http://cdimages.ubuntu.com/daily-live/current/

But if you do find any problems with 19.04 then please open new bugs for those.

[Shambler (jbarrett847)]

See this bug:
https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe/+bug/1821441

It looks like (at least for some people) there was a wider root cause - confirmed by the trace in comments above, where expensive clock_gettime calls are observed.

[Satya (satya-bangalore)]

I see same behaviour. recvmsg() with EAGAIN failures (lot!!). CPU utilization is not very high for me. Like around 3% but constant usage. I could see difference in battery life. Switched back to unity for now.

I see the status as "Fix released". Which ubuntu version has the fix?

Or is it possible to get the fix for 18.04 too (via gnome-shell update?)?

[Daniel van Vugt (vanvugt)]

This bug is closed because:

 (a) The original reporter can't reproduce it any more; and
 (b) The developer can't reproduce it any more.

If there are any remaining issues then please open a new bug by running:

  ubuntu-bug gnome-shell

[Greggth (greggth)]

Expanding on Shambler's 2019/03/23 comment, clock_gettime showing up in the strace can be caused by the TSC clock source being marked unstable (after a sleep for some people, like me).