Как найти причину высокой загрузки ЦП gnome-shell?
Я на 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
5 ответов
Возможно, попробуйте использовать 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), подождите некоторое время, чтобы собрать приличный объем информации, а затем удалит политику аудита. Внимательно изучите файл audd.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
Удачи!
Причин может быть несколько:
Часы с секундами:
gsettings set org.gnome.desktop.interface clock-show-seconds falseindicator-multiload(Монитор использования процессора и т. д. на панели)Процесс можно назвать в меню: Индикатор загрузки системы.
Просто остановите процесс (или перед его остановкой) отключите опцию автозапуска. Также помогает установка более длительного времени для зондирования, например 10 секунд. делает все приложение бесполезным.
Что-нибудь с мониторингом «в реальном времени», диском, процессором, сетью.
Для тех, кто сталкивается с подобной проблемой. Проверьте, что вы используете. Xorg или Wayland. Если маршрут изменился на xorg, и все стало хорошо.
apt install inxi
inxi -t cm
Процессы: процессор -% использования - топ 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.34 МБ (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
я использовалindicator-multiloadкоторый использовал слишком много процессора, даже если я установил время обновления на 10 секунд.
Я удалил его с помощьюaptа потом я установилgnome-system-monitorкоторый делает то же самое, но более эффективно.