25

I'm on a Linux Fedora 23 and I recently noticed that my gnome-shell process constantly uses 100% of one CPU (reported by htop, no visible applications running). There are some hints out there which cover some workarounds for bugs in the gnome-shell (deactivating background logo, re-aligning the monitors) but none of them help.

I tried to run

perf top

which reports the most work in the following symbols:

22.55%  [kernel]                            [k] acpi_ns_search_one_scope
11.41%  [kernel]                            [k] acpi_ex_system_memory_space_h
 5.27%  [kernel]                            [k] _raw_spin_lock_irqsave
 5.23%  [kernel]                            [k] _raw_write_unlock_irqrestore
 3.52%  [kernel]                            [k] acpi_ut_update_object_referen
 ...

Then I tried to closer look into the gnome-shell process with

perf record -g -p PID
perf report -g

but the output seems to be useless:

  Children      Self  Command      Shared Object                 Symbol       
-   29.08%     0.00%  gnome-shell  [unknown]                     [.] 000000000
   - 0                                                                        
      + 55.88% 0                                                              
      + 8.25% 0x85a81                                                         
      + 6.87% 0x2                                                             
      + 5.94% 0x4                                                             
      + 4.60% 0x889fc                                                         
        3.32% 0x656c6261                                                      
      + 2.39% 0x8feab                                                         
        2.23% 0x88467                                                         
      + 1.26% 0x190800002800                                                  
      + 1.24% 0xffad7fa800100008                                              
        1.23% 0xc82ca96051913c58                                              
        1.20% 0x5602c82afa00                                                  
      + 1.18% 0x1                                                             
        1.16% 0x89e84                                                         
        1.10% 0x5602c7c68830                                                  
        1.08% 0x5602c900736e                                                  
      + 1.08% 0x7ffe4bfd1001                                                  
-   21.48%     0.00%  gnome-shell  [kernel.kallsyms]             [k] entry_SYS
   - entry_SYSCALL_64_fastpath                                                
      + 43.62% __GI___ioctl                                                   
      + 18.92% 0xf6fdd                                                        
      + 12.90% __GI___libc_open                                               
      + 5.21% 0xfb4d                                                          
      + 3.92% __GI___libc_recvmsg                                             
      + 2.89% _IO_file_read                                                   
      + 2.75% __socket                                                        
      + 2.74% __GI___libc_read                                                
      + 1.41% __GI___mmap64                                                   
      + 1.39% __GI___libc_recvmsg                                             
        1.30% 0x103b73                                                        
      + 0.77% __GI___writev                                                   
        0.74% __statfs                                                        
      + 0.74% _IO_file_open                                                   
        0.71% __GI___munmap                                                   
+    9.37%     0.00%  gnome-shell  libc-2.22.so                  [.] __GI___io
+    9.37%     0.00%  gnome-shell  [kernel.kallsyms]             [k] sys_ioctl

Do you have a hint for me what I could do to to inspect what's going on on my system?

I'm on a Skylake i5 6260u with Intel Iris 540 with Fedora running kernel 4.3.3-300.fc23.x86_64

4
  • I have the same issue on Arch Linux, kernel 4.5.1, with a i7-2600
    – Florian Bw
    May 6, 2016 at 18:40
  • Have you tried setting no image on the desktop background?
    – frans
    May 6, 2016 at 19:34
  • I'm having same issue on Ubuntu 17.10 with a Lenovo G50. Disappointed that no one has addressed this question.
    – TheGeeko61
    Apr 20, 2018 at 5:47
  • havent test the solution, but so far, i realise my chrome browser and visual code with some cpu activity above 50% could cause gnome-shell to go beyond 30% cpu. once i pkill chrome or pkill code, the gnome-shell cpu went down to less than 5% on average
    – James Tan
    Jan 4, 2022 at 17:42

4 Answers 4

14

Perhaps try using auditd, which would roughly be something like:

sudo yum install auditd  # sudo apt install auditd on Debian
sudo auditctl -a exit,always -S all -F pid=1234 & sleep 15
sudo auditctl -d exit,always -S all -F pid=1234
less /var/log/audit/audit.log

This will install and start auditd, set a policy to capture system call info for your PID (1234 in the example), wait for a short while to capture a decent amount of info, then remove the audit policy. Take a good look over the auditd.log for your gnome-terminal PID, you may get a better idea of what it's busy doing.

Another quick tool for spotting what a process is spending it's time doing is just strace, wait a short time, then hit Ctrl + C:

$ sudo strace -c -p 1234
strace: Process 1234 attached
^Cstrace: Process 1234 detached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 56.98    0.003496         388         9           clone
 17.19    0.001055           8       135           rt_sigprocmask
  6.19    0.000380          21        18         9 wait4
  4.58    0.000281          16        18           close
  3.80    0.000233          26         9           read
  3.47    0.000213          24         9           stat
  3.37    0.000207          23         9         9 rt_sigsuspend
  3.08    0.000189          21         9           pipe
  1.34    0.000082           9         9         9 rt_sigreturn
------ ----------- ----------- --------- --------- ----------------
100.00    0.006136                   225        27 total

Then if you want to learn more, check the appropriate man page for the system call you're looking at:

$ man -s2 clone
2
  • 3
    perf is great for examining what the kernel is busy doing, but as you suspect this CPU usage problem was caused in userland, you're best off looking at system calls. I recently used the auditd method (with '-S execve' and no '-F ...' to restrict the policy to just watch all 'execve' system calls) to track down what process/daemon was calling 'zpool get' every ten seconds. Very quickly learned it was docker!
    – trcm
    May 1, 2018 at 16:43
  • 1
    You can use timeout to stop auditctl
    – Pablo A
    Jun 12, 2021 at 4:50
4

There could be several causes of it:

  1. Clock with seconds:

    gsettings set org.gnome.desktop.interface clock-show-seconds false
    
  2. indicator-multiload (CPU etc. usage monitor in bar)

    Process could be named in menu: System Load Indicator.

    Just stop process (or before stopping it) disable autostart option. Setting longer time for probing also helps, but for example 10 sec. makes the whole app useless.

  3. Anything with "real time" monitoring, disk, CPU, network.

2
  • 6
    To me, it was System Load Indicator (kind of ironic that a tool to monitor the system performance causes performance issues :)
    – Alejandro
    May 11, 2021 at 22:24
  • 1
    System load indicator it was also for me...
    – RogerS
    Jul 1, 2021 at 13:19
1

For anyone who encounters a similar problem. Check that you are using. Xorg or wayland. If the wayland is changed to xorg and everything becomes ok.

4
  • How should one check this?
    – d.k
    Nov 23, 2018 at 3:39
  • 1
  • While this is not an answer, I upvoted back to 0, because this may be an important factor. E.g. I had 100% cpu on wayland while the other wayland session was runing. Havent seen it on xorg
    – jaromrax
    Dec 17, 2022 at 15:06
  • And I up-voted it to "1", as I have similar problem (>500cpu usage when gnome-control-settings is open and I do not touch anything), which exists only under wayland.
    – lacek
    Nov 7, 2023 at 6:06
0

I was using indicator-multiload which was using too much CPU even if I set the refresh time to 10 seconds.

I removed it with apt and then I installed gnome-system-monitor which does the same thing but more efficiently.

You must log in to answer this question.

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