GUI Laggy slow response after updates

@JonathanYoung2161 Hi and welcome to the Forum.
What spec is your CPU and how much RAM do you have?
Although Zorin website specifies System Requirements https://zorinos.com/help/system-requirements/ that should be considered the minimum.
We have seen cases where users try running with minimum RAM and find the OS unusable.
Have you tried Zorin 15.3 Lite?

Vega 64 threadripper x1950 64 gigs of RAM the computer meets and exceeds all system requirements

Can you check on System Monitor to see what processes may be taking up the most CPU & Memory?
PS - I’m guessing the 64 gigs of RAM is a typo.

64 gigabytes of RAM no typo

That’s a monster. I’m still in the medieval era with less than a tenth of that on my desktop.
So, anything on System Monitor?

I’ll be checking in an hour or two when I get home… well it never fails Windows just keeps getting bigger and bigger it’s the blue dragon an average PC that would run Linux fantastically is a piece of ■■■■ on Windows

Nothing even at 1% CPU usage and the biggest memory usage is 231 Meg and that’s the gnome shell

Little more information the mouse does not show any lag but when I click on anything on the GUI there is a decent delay between response and when typing there is a delay between response but the mouse has no delay when moving across the screen

1 Like

In an effort to track down the issue I am trying zorin lite to see if the issue follows

You can also try iotop and tail as mentioned here. htop isn’t needed since you checked on System Monitor.
Did you try switching drivers under Zorin Menu -> System Tools -> Software Updater -> Settings -> Additional Drivers?
Also, since you upgraded, it may be worth just trying a clean Core 15 install instead of upgrading from 12.
But you can let us know first what you find out about Lite.

Yes the first thing I did was a clean install of zorin ultimate 12 and then zorin ultimate 15. 3

Under additional drivers there are none available this was the same results found in KDE and kubuntu

~$ tail -f /var/log/kern.log
Dec 10 19:40:42 omega-MS-7B09 kernel: [ 10.690919] EDAC MC: UMC1 chip selects:
Dec 10 19:40:42 omega-MS-7B09 kernel: [ 10.690919] EDAC amd64: MC: 0: 0MB 1: 0MB
Dec 10 19:40:42 omega-MS-7B09 kernel: [ 10.690920] EDAC amd64: MC: 2: 8192MB 3: 8192MB
Dec 10 19:40:42 omega-MS-7B09 kernel: [ 10.690921] EDAC amd64: using x8 syndromes.
Dec 10 19:40:42 omega-MS-7B09 kernel: [ 10.690921] EDAC amd64: MCT channel count: 2
Dec 10 19:40:42 omega-MS-7B09 kernel: [ 10.690987] EDAC MC1: Giving out device to module amd64_edac controller F17h: DEV 0000:00:19.3 (INTERRUPT)
Dec 10 19:40:42 omega-MS-7B09 kernel: [ 10.690998] EDAC PCI0: Giving out device to module amd64_edac controller EDAC PCI controller: DEV 0000:00:18.0 (POLLED)
Dec 10 19:40:42 omega-MS-7B09 kernel: [ 10.690998] AMD64 EDAC driver v3.5.0
Dec 10 19:41:04 omega-MS-7B09 kernel: [ 33.249399] usb 5-1.2: 3:1: cannot set freq 48000 to ep 0x82
Dec 10 19:41:07 omega-MS-7B09 kernel: [ 36.000414] rfkill: input handler disabled

I don’t know if the memory related logs would be an issue (EDAC).
Last ones certainly wouldn’t - USB and wireless.
Can you try keeping System Monitor open (try with Resources tab and then Processes) and then click your mouse or start typing and see if there are any spikes?

The only thing that acts up is gnome shell taking 1 processor to 44%

Changing a few bios settings see if that’ll help if it doesn’t I’ll probably change out the ram I have a spare set sitting here see if that helps if you have any ideas feel free to share… the thing that blows my mind is that upon first installation before software updates it’s nice and fast and works great and other distros I’ve tried or not having issues so something’s not playing nice

Can you try, during boot, to see if an older kernel is available to boot into? I forgot which one of the GRUB options it is. If you have trouble getting into it, hold Shift or tap ESC (one of the two will work for you).

The only thing I can find on shell is this: https://askubuntu.com/questions/1036441/ubuntu-18-04-gnome-shell-high-cpu-usage - a lot of different reasons.

Looks like we’re good to go it was a bios setting

Disabled Windows 10 whql support issue resolved

Thank you for your time highly appreciated

3 Likes