How to find the cause for high CPU usage of gnome-shell?

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

3 Answers

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

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 whole app useless.

3. anything with "real time" monitoring, disk, cpu, network

2

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.

2

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password Submit

Post as a guest

Post Your Answer Discard

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy