我刚刚在 Dell Latitude 7370 上将 Ubuntu 18.04 LTS 升级到 20.04 LTS。用户界面和所有应用程序每 5-10 秒就会滞后/冻结 2-3 秒。使用 18.04 时我没有遇到这样的问题。似乎当 gnome-s+ 使用 50% 到 90% 的 CPU 时会发生这种情况。以下是不同的日志。在此先感谢您的帮助。
top - 17:59:05 up 1 day, 1:32, 1 user, load average: 0,76, 0,88, 1,57
Tâches: 241 total, 2 en cours, 239 en veille, 0 arrêté, 0 zombie
%Cpu(s): 17,6 ut, 1,1 sy, 0,0 ni, 81,0 id, 0,0 wa, 0,0 hi, 0,3 si, 0,0 st
MiB Mem : 7853,6 total, 2647,7 libr, 2096,1 util, 3109,8 tamp/cache
MiB Éch: 976,0 total, 976,0 libr, 0,0 util. 4721,7 dispo Mem
PID UTIL. PR NI VIRT RES SHR S %CPU %MEM TEMPS+ COM.
2460 ubuntop+ 20 0 4723020 322520 114568 R 67,9 4,0 42:02.04 gnome-s+
2309 ubuntop+ 20 0 937828 161780 108616 S 2,6 2,0 10:43.89 Xorg
10365 ubuntop+ 20 0 966096 53264 40208 S 1,7 0,7 0:04.81 gnome-t+
2246 ubuntop+ 20 0 10952 8088 4116 S 0,7 0,1 0:11.41 dbus-da+
4141 ubuntop+ 20 0 781220 104100 53816 S 0,7 1,3 0:21.29 megasync
9661 ubuntop+ 20 0 4086332 602808 262408 S 0,7 7,5 4:17.07 MainThr+
1 root 20 0 168116 11952 8320 S 0,3 0,1 0:08.20 systemd
1085 message+ 20 0 10304 6824 4088 S 0,3 0,1 0:06.62 dbus-da+
2506 ubuntop+ 20 0 162820 7624 6848 S 0,3 0,1 0:02.58 at-spi2+
9734 ubuntop+ 20 0 2671228 311604 250824 S 0,3 3,9 0:38.86 Web Con
免费-h
total utilisé libre partagé tamp/cache disponible
Mem: 7,7Gi 2,1Gi 2,2Gi 1,1Gi 3,4Gi 4,2Gi
Partition d'échange: 975Mi 0B 975Mi
sysctl vm.swappiness= 60
ls -al /usr/share/gnome-shell/extensions
total 20
drwxr-xr-x 5 root root 4096 sep 30 11:27 .
drwxr-xr-x 7 root root 4096 sep 30 11:31 ..
drwxr-xr-x 2 root root 4096 sep 30 11:27 desktop-icons@csoriano
drwxr-xr-x 3 root root 4096 sep 30 11:19 [email protected]
drwxr-xr-x 3 root root 4096 sep 30 11:19 [email protected]
sudo dmidecode -s bios 版本1.18.5
sudo lshw -C 内存
*-firmware
description: BIOS
fabricant: Dell Inc.
identifiant matériel: 0
version: 1.18.5
date: 10/08/2019
taille: 64KiB
capacité: 16MiB
fonctionnalités: pci pnp upgrade shadowing cdboot bootselect edd int13floppy1200 int13floppy720 int13floppy2880 int5printscreen int9keyboard int14serial int17printer acpi usb smartbattery biosbootspecification netboot uefi
*-cache:0
description: L1 cache
identifiant matériel: 3c
emplacement: L1 Cache
taille: 64KiB
capacité: 64KiB
fonctionnalités: synchronous internal write-back data
configuration : level=1
*-cache:1
description: L1 cache
identifiant matériel: 3d
emplacement: L1 Cache
taille: 64KiB
capacité: 64KiB
fonctionnalités: synchronous internal write-back instruction
configuration : level=1
*-cache:2
description: L2 cache
identifiant matériel: 3e
emplacement: L2 Cache
taille: 512KiB
capacité: 512KiB
fonctionnalités: synchronous internal write-back unified
configuration : level=2
*-cache:3
description: L3 cache
identifiant matériel: 3f
emplacement: L3 Cache
taille: 4MiB
capacité: 4MiB
fonctionnalités: synchronous internal write-back unified
configuration : level=3
*-memory
description: Mémoire Système
identifiant matériel: 41
emplacement: Carte mère
taille: 8GiB
*-bank:0
description: SODIMM LPDDR3 Synchrone 1600 MHz (0,6 ns)
produit: 0
fabricant: 0
identifiant matériel: 0
numéro de série: 0
emplacement: System Board Memory
taille: 4GiB
bits: 64 bits
horloge: 1600MHz (0.6ns)
*-bank:1
description: SODIMM LPDDR3 Synchrone 1600 MHz (0,6 ns)
produit: 0
fabricant: 0
identifiant matériel: 1
numéro de série: 0
emplacement: System Board Memory
taille: 4GiB
bits: 64 bits
horloge: 1600MHz (0.6ns)
*-memory NON-RÉCLAMÉ
description: Memory controller
produit: Sunrise Point-LP PMC
fabricant: Intel Corporation
identifiant matériel: 1f.2
information bus: pci@0000:00:1f.2
version: 21
bits: 32 bits
horloge: 33MHz (30.3ns)
configuration : latency=0
ressources : mémoire:dc32c000-dc32ffff
ls -al ~/.local/share/gnome-shell/extensions
ls: cannot access '/home/ubuntophe/.local/share/gnome-shell/extensions': No such file
英希-G
Graphics:
Device-1: Intel HD Graphics 515 driver: i915 v: kernel
Display: x11 server: X.Org 1.20.8 driver: i915 resolution: 3200x1800~60Hz
OpenGL: renderer: Mesa Intel HD Graphics 515 (SKL GT2) v: 4.6 Mesa 20.0.8
答案1
罪魁祸首是Megasync 客户端当客户端关闭后，一切恢复正常，系统顺利运行。
我不知道为什么，但是当 Megasync Client 打开，并且导致整个系统滞后时，它并没有显示 CPU% 使用率的增加，但是却top显示。Megasyncgnome-s+
抱歉这么晚才发布解决方案，感谢大家的支持。
答案2
在我的案例中，罪魁祸首与ibus 守护进程。我早就想了解为什么 ibus 会导致这种情况，但在这方面我仍然一无所知。
就我的情况而言，无论我是否让 PC 进入睡眠状态，ibus 只会在 PC 运行大约 2 天后（减去睡眠时间）才开始引起问题。