Wie finde ich die Ursache für die hohe CPU-Auslastung von gnome-shell?

11899
frans

Ich bin auf einem Linux-Fedora-23-System und habe kürzlich festgestellt, dass mein gnome-shellProzess ständig 100% einer CPU verwendet (gemeldet von htop, keine sichtbaren Anwendungen laufen). Es gibt einige Hinweise, die einige Problemumgehungen für Fehler im gnome-shell(inaktivierendes Hintergrundlogo, Neuausrichten der Monitore) enthalten, aber keiner von ihnen hilft.

Ich habe versucht zu rennen

perf top 

welche die meiste Arbeit in den folgenden Symbolen meldet:

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

Dann habe ich versucht den gnome-shellProzess mit näher zu untersuchen

perf record -g -p PID perf report -g 

aber die Ausgabe scheint nutzlos zu sein:

 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 

Haben Sie einen Hinweis für mich, was ich tun könnte, um zu überprüfen, was in meinem System vorgeht?

Ich bin auf einem Skylake i5 6260u mit Intel Iris 540 und Fedora mit dem Kernel 4.3.3-300.fc23.x86_64

11
Ich habe das gleiche Problem auf Arch Linux, Kernel 4.5.1, mit einem i7-2600 Florian Bw vor 8 Jahren 0
Haben Sie versucht, kein Bild auf dem Desktop-Hintergrund einzustellen? frans vor 8 Jahren 0
Ich habe dasselbe Problem mit Ubuntu 17.10 mit einem Lenovo G50. Enttäuscht, dass niemand diese Frage angesprochen hat. TheGeeko61 vor 6 Jahren 0

3 Antworten auf die Frage

3
trcm

Versuchen Sie es vielleicht mit auditd, was ungefähr so ​​aussieht:

$ 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 

Dadurch wird auditd installiert und gestartet, eine Richtlinie zum Erfassen von Systemanrufinformationen für Ihre PID (im Beispiel 1234) festgelegt. Warten Sie eine kurze Zeit, um eine anständige Menge an Informationen zu erfassen, und entfernen Sie dann die Überwachungsrichtlinie. Werfen Sie einen genaueren Blick auf die auditd.log-Datei für Ihr gnome-terminal PID. Sie erhalten möglicherweise eine bessere Vorstellung davon, was es gerade zu tun hat.

Ein weiteres schnelles Werkzeug zum Erkennen dessen, was ein Prozess damit verbringt, ist es, nur zu warten, eine kurze Zeit zu warten und dann STRG-c zu drücken:

$ 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 

Wenn Sie mehr erfahren möchten, überprüfen Sie die entsprechende Manpage für den Systemaufruf, den Sie gerade sehen:

$ man -s2 clone 

Viel Glück!

perf eignet sich hervorragend zum Untersuchen, was der Kernel gerade tut, aber da Sie vermuten, dass dieses CPU-Nutzungsproblem in userland verursacht wurde, sollten Sie sich am besten Systemaufrufe ansehen. Ich habe kürzlich die auditd-Methode verwendet (mit '-S execve' und keinem '-F ...', um die Richtlinie einzuschränken, um nur alle 'execve'-Systemaufrufe zu überwachen), um herauszufinden, welcher Prozess / Daemon' zpool get 'aufgerufen hat zehn Sekunden. Sehr schnell lernte es Docker! trcm vor 6 Jahren 1
0
chanchal sakarde

apt install inxi inxi -t cm

Prozesse: CPU -% used - Top 5 aktiv 1: cpu: 100% Befehl: gnome-shell pid: 1980 2: cpu: 1,1% befehl: java pid: 1425 3: cpu: 0,1% befehl: java pid: 2949 4: cpu: 0.0% Befehl: bash pid: 32516 5: cpu: 0,0% Befehl: su pid: 32515 Speicher - MB /% belegt - Top 5 aktiv 1: mem: 5613.34MB (35.2%) Befehl: gnome-shell pid: 1980 2: mem: 3256.19MB (20.4%) Befehl: gnome-settings-daemon pid: 1647 3: mem: 2305.28MB (14.4%) Befehl: java pid: 1425 4: mem: 1048.82MB (6,5%) Befehl: java pid: 2949 5: mem: 225,59 MB (1,4%) Befehl: Java Pid: 2619 
Wie zeigt das, was genau in gnome-shell den CPU-Peak verursacht? confetti vor 6 Jahren 1
-1
Someone

Für alle, die ein ähnliches Problem haben. Überprüfen Sie, ob Sie verwenden. Xorg oder Wayland. Wenn das Wayland in Xorg geändert wird und alles in Ordnung ist.

Wie soll man das überprüfen? user907860 vor 5 Jahren 0
https://unix.stackexchange.com/questions/202891/wie-zu- wissen- ob-wege-oder-x11-wird-verwendet Someone vor 5 Jahren 1