Как найти причину высокой загрузки ЦП gnome-shell?

11833
frans

Я использую Linux Fedora 23, и недавно я заметил, что мой gnome-shellпроцесс постоянно использует 100% одного процессора (по сообщениям htop, видимых приложений не запущено). Есть некоторые подсказки, которые охватывают некоторые обходные пути для ошибок в gnome-shell(деактивация фонового логотипа, повторное выравнивание мониторов), но ни один из них не помогает.

Я пытался бежать

perf top 

который сообщает больше всего работы в следующих символах:

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 ... 

Затем я попытался поближе взглянуть на gnome-shellпроцесс с

perf record -g -p PID perf report -g 

но вывод кажется бесполезным:

 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 

У вас есть подсказка для меня, что я могу сделать, чтобы проверить, что происходит в моей системе?

Я на Skylake i5 6260u с Intel Iris 540 с Fedora под управлением ядра 4.3.3-300.fc23.x86_64

11
У меня такая же проблема на Arch Linux, ядро ​​4.5.1, с i7-2600 Florian Bw 7 лет назад 0
Вы пробовали не устанавливать изображение на фоне рабочего стола? frans 7 лет назад 0
У меня та же проблема на Ubuntu 17.10 с Lenovo G50. Разочарован тем, что никто не обратился к этому вопросу. TheGeeko61 6 лет назад 0

3 ответа на вопрос

3
trcm

Возможно, попробуйте использовать audd, который примерно будет выглядеть примерно так:

$ sudo yum install auditd $ 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 

Это установит и запустит audd, установит политику для сбора информации о системных вызовах для вашего PID (в примере 1234), подождите некоторое время, чтобы собрать приличный объем информации, а затем удалит политику аудита. Внимательно изучите файл Audit.log для PID терминала gnome, вы можете лучше понять, чем он занят.

Еще один быстрый инструмент для определения того, что процесс тратит на свое время, - просто остановитесь, подождите немного, а затем нажмите 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 

Затем, если вы хотите узнать больше, проверьте соответствующую справочную страницу для системного вызова, который вы просматриваете:

$ man -s2 clone 

Удачи!

Программа perf отлично подходит для изучения того, чем занимается ядро, но, как вы подозреваете, эта проблема использования процессора была вызвана в пользовательской среде, лучше всего смотреть на системные вызовы. Недавно я использовал метод audd (с «-S execve» и без «-F ...», чтобы ограничить политику только просмотром всех системных вызовов «execve»), чтобы отследить, какой процесс / демон вызывал каждый раз «zpool get» десять секунд Очень быстро узнал, что это докер! trcm 5 лет назад 1
0
chanchal sakarde

apt install inxi inxi -t cm

Процессы: CPU -% использования - топ 5 активных 1: процессор: 100% команда: pid гнома: 1980 2: процессор: 1,1% команда: Java PID: 1425 3: процессор: 0,1% команда: Java PID: 2949 4: процессор: 0,0% команда: bash pid: 32516 5: процессор: 0,0% команда: su pid: 32515 Память - используется МБ /% - 5 активных 1: mem: 5613.34MB (35,2%) команда: pid gnome-shell: 1980 2: mem: 3256.19MB (20,4%) команда: gnome-settings-daemon pid: 1647 3: mem: 2305,28 МБ (14,4%) команда: Java PID: 1425 4: mem: 1048,82 МБ (6,5%) команда: Java PID: 2949 5: mem: 225,59 МБ (1,4%) команда: Java PID: 2619 
Как это показывает, что именно в gnome-shell вызывает пик процессора? confetti 5 лет назад 1
-1
Someone

Для тех, кто сталкивается с подобной проблемой. Проверьте, что вы используете. Xorg или Wayland. Если маршрут изменился на xorg и все стало хорошо.

Как это проверить? user907860 5 лет назад 0
https://unix.stackexchange.com/questions/202891/how-to-know-whether-wayland-or-x11-is-being-used Someone 5 лет назад 1

Похожие вопросы