Overall system slugishness - How to diagnose problem?

Hello,

I have been using Garuda for some time already. Overally I love it however some time ago it has started being a bit sluggish.
There is a lag when opening a new window terminal, new browser etc. Sometimes even right after the start-up. Weirdly enough, cpu/ram usage hardly ever get even close to 80%, still things are less responsive than they used to be.

Could you help me diagonising the potential cause of the problem, and then solve it if possible?

Well there are utilities to monitor resource usage, I would suggest disk utilitzation, memory utilization, and cpu utilization.
The tools you choose may vary, depending on your technical expertise, so I'm not going to recommend any, other than saying google is your friend.
The quickest and easiest thing to try though is an older or more recent kernel. It can make a huge difference. And the most obvious thing, if you haven't tried it, just reboot and see if it persists...sometimes strange things happen (possibly related to an update w/o rebooting).
Check your system log for warnings, errors too. Other things I've noticed are swap device UUID has changed (ie installing a distro that changed it) this can dramatically increase system lag. Also DNS resolution issues..wow that can really FU the whole thing.

2 Likes

Read

please
and post

inxi -Fxxxza

as text!

and
:slight_smile:

1 Like

I traced cpu/mem, they are unlikley to be the problem.
Disk usage, that I haven't checked. Will monitor.

Password to privtebins : qwerty

journalctl -p crit -b -1

https://bin.garudalinux.org/?8e14d63601d993d0#EiKeoodnu2BDPE3gTi7RSMHwVtr64Reikn5Bb8ua9BWw

journalctl -p err -b -1

https://bin.garudalinux.org/?162d8f847638b141#GrEH92drVTyZBumLEgWdwjYTmai5pRdfBbWr2h3e6wc3

Output of inxi:

System:    Kernel: 5.10.15-120-tkg-bmq x86_64 bits: 64 compiler: gcc v: 10.2.1 
           parameters: intel_pstate=passive BOOT_IMAGE=/@/boot/vmlinuz-linux-tkg-bmq 
           root=UUID=7c0ee5b1-d098-439b-8ff8-fb0d1c6f0d5a rw rootflags=subvol=@ quiet 
           cryptdevice=UUID=3fe1c118-dacc-4aa4-93c7-1505075cc962:luks-3fe1c118-dacc-4aa4-93c7-1505075cc962 
           root=/dev/mapper/luks-3fe1c118-dacc-4aa4-93c7-1505075cc962 splash 
           rd.udev.log_priority=3 vt.global_cursor_default=0 systemd.unified_cgroup_hierarchy=1 
           loglevel=3 
           Console: N/A wm: kwin_x11 DM: SDDM Distro: Garuda Linux 
Machine:   Type: Laptop System: Dell product: XPS 15 9550 v: N/A serial: <filter> Chassis: 
           type: 9 serial: <filter> 
           Mobo: Dell model: 0N7TVV v: A01 serial: <filter> UEFI: Dell v: 1.14.0 date: 02/13/2020 
Battery:   ID-1: BAT0 charge: 44.2 Wh condition: 44.2/84.0 Wh (53%) volts: 12.5/11.4 
           model: SMP DELL 1P6KD54 type: Li-poly serial: <filter> status: Full 
CPU:       Info: Quad Core model: Intel Core i7-6700HQ socket: U3E1 bits: 64 type: MT MCP 
           arch: Skylake-S family: 6 model-id: 5E (94) stepping: 3 microcode: E2 
           L1 cache: 256 KiB L2 cache: 6 MiB L3 cache: 5.9 MiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 41646 
           Speed: 800 MHz min/max: 800/2600 MHz base/boost: 2600/2600 volts: 0.9 V 
           ext-clock: 100 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 800 5: 800 6: 800 7: 800 
           8: 800 
           Vulnerabilities: Type: itlb_multihit status: KVM: VMX disabled 
           Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable 
           Type: mds mitigation: Clear CPU buffers; SMT vulnerable 
           Type: meltdown mitigation: PTI 
           Type: spec_store_bypass 
           mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, 
           STIBP: conditional, RSB filling 
           Type: srbds mitigation: Microcode 
           Type: tsx_async_abort mitigation: Clear CPU buffers; SMT vulnerable 
Graphics:  Device-1: Intel HD Graphics 530 vendor: Dell XPS 15 9550 driver: i915 v: kernel 
           bus ID: 00:02.0 chip ID: 8086:191b class ID: 0300 
           Device-2: NVIDIA GM107M [GeForce GTX 960M] vendor: Dell XPS 15 9550 driver: nvidia 
           v: 460.39 alternate: nouveau,nvidia_drm bus ID: 01:00.0 chip ID: 10de:139b 
           class ID: 0302 
           Device-3: Microdia Integrated_Webcam_HD type: USB driver: uvcvideo bus ID: 1-12:5 
           chip ID: 0c45:6713 class ID: 0e02 
           Display: server: X.Org 1.20.10 compositor: kwin_x11 driver: loaded: modesetting,nvidia 
           alternate: fbdev,intel,nouveau,nv,vesa display ID: :0 screens: 1 
           Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.0x11.2") 
           s-diag: 582mm (22.9") 
           Monitor-1: eDP-1 res: 1920x1080 hz: 60 dpi: 141 size: 346x194mm (13.6x7.6") 
           diag: 397mm (15.6") 
           OpenGL: renderer: Mesa Intel HD Graphics 530 (SKL GT2) v: 4.6 Mesa 20.3.4 
           direct render: Yes 
Audio:     Device-1: Intel 100 Series/C230 Series Family HD Audio vendor: Dell XPS 15 9550 
           driver: snd_hda_intel v: kernel bus ID: 00:1f.3 chip ID: 8086:a170 class ID: 0403 
           Device-2: AudioQuest DragonFly Red type: USB driver: hid-generic,snd-usb-audio,usbhid 
           bus ID: 1-1:2 chip ID: 21b4:0082 class ID: 0300 serial: <filter> 
           Device-3: C-Media Blue Snowball type: USB driver: hid-generic,snd-usb-audio,usbhid 
           bus ID: 1-2:3 chip ID: 0d8c:0005 class ID: 0300 serial: <filter> 
           Sound Server: ALSA v: k5.10.15-120-tkg-bmq 
Network:   Device-1: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter 
           vendor: Rivet Networks driver: ath10k_pci v: kernel port: e000 bus ID: 02:00.0 
           chip ID: 168c:003e class ID: 0280 
           IF: wlp2s0 state: up mac: <filter> 
           Device-2: Qualcomm Atheros QCA61x4 Bluetooth 4.0 type: USB driver: btusb bus ID: 1-4:4 
           chip ID: 0cf3:e300 class ID: e001 
           Device-3: Realtek RTL8153 Gigabit Ethernet Adapter type: USB driver: r8152 
           bus ID: 4-1.4:3 chip ID: 0bda:8153 class ID: 0000 serial: <filter> 
           IF: enp62s0u1u4 state: up speed: 1000 Mbps duplex: full mac: <filter> 
           IF-ID-1: br-20605da9f597 state: down mac: <filter> 
           IF-ID-2: docker0 state: down mac: <filter> 
Bluetooth: Device-1: Qualcomm Atheros QCA61x4 Bluetooth 4.0 type: USB driver: btusb v: 0.8 
           bus ID: 1-4:4 chip ID: 0cf3:e300 class ID: e001 
           Message: Required tool hciconfig not installed. Check --recommends 
Drives:    Local Storage: total: 476.94 GiB used: 59.77 GiB (12.5%) 
           ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Toshiba model: THNSN5512GPU7 NVMe 512GB 
           size: 476.94 GiB block size: physical: 512 B logical: 512 B speed: 31.6 Gb/s lanes: 4 
           rotation: SSD serial: <filter> rev: 57DA4103 temp: 36.9 C scheme: GPT 
           SMART: yes health: PASSED on: 307d 0h cycles: 5,758 read-units: 38,809,820 [19.8 TB] 
           written-units: 48,630,520 [24.8 TB] 
Partition: ID-1: / raw size: 155.5 GiB size: 155.5 GiB (100.00%) used: 59.72 GiB (38.4%) 
           fs: btrfs block size: 4096 B dev: /dev/dm-0 maj-min: 254:0 
           mapped: luks-3fe1c118-dacc-4aa4-93c7-1505075cc962 
           ID-2: /boot/efi raw size: 100 MiB size: 96 MiB (96.00%) used: 44.4 MiB (46.3%) 
           fs: vfat block size: 512 B dev: /dev/nvme0n1p2 maj-min: 259:2 
           ID-3: /home raw size: 155.5 GiB size: 155.5 GiB (100.00%) used: 59.72 GiB (38.4%) 
           fs: btrfs block size: 4096 B dev: /dev/dm-0 maj-min: 254:0 
           mapped: luks-3fe1c118-dacc-4aa4-93c7-1505075cc962 
           ID-4: /var/log raw size: 155.5 GiB size: 155.5 GiB (100.00%) used: 59.72 GiB (38.4%) 
           fs: btrfs block size: 4096 B dev: /dev/dm-0 maj-min: 254:0 
           mapped: luks-3fe1c118-dacc-4aa4-93c7-1505075cc962 
           ID-5: /var/tmp raw size: 155.5 GiB size: 155.5 GiB (100.00%) used: 59.72 GiB (38.4%) 
           fs: btrfs block size: 4096 B dev: /dev/dm-0 maj-min: 254:0 
           mapped: luks-3fe1c118-dacc-4aa4-93c7-1505075cc962 
Swap:      Kernel: swappiness: 10 (default 60) cache pressure: 75 (default 100) 
           ID-1: swap-1 type: zram size: 1.94 GiB used: 0 KiB (0.0%) priority: 32767 
           dev: /dev/zram0 
           ID-2: swap-2 type: zram size: 1.94 GiB used: 0 KiB (0.0%) priority: 32767 
           dev: /dev/zram1 
           ID-3: swap-3 type: zram size: 1.94 GiB used: 0 KiB (0.0%) priority: 32767 
           dev: /dev/zram2 
           ID-4: swap-4 type: zram size: 1.94 GiB used: 0 KiB (0.0%) priority: 32767 
           dev: /dev/zram3 
           ID-5: swap-5 type: zram size: 1.94 GiB used: 0 KiB (0.0%) priority: 32767 
           dev: /dev/zram4 
           ID-6: swap-6 type: zram size: 1.94 GiB used: 0 KiB (0.0%) priority: 32767 
           dev: /dev/zram5 
           ID-7: swap-7 type: zram size: 1.94 GiB used: 0 KiB (0.0%) priority: 32767 
           dev: /dev/zram6 
           ID-8: swap-8 type: zram size: 1.94 GiB used: 0 KiB (0.0%) priority: 32767 
           dev: /dev/zram7 
Sensors:   System Temperatures: cpu: 63.5 C mobo: N/A 
           Fan Speeds (RPM): cpu: 2512 fan-2: 2504 
Info:      Processes: 299 Uptime: 52m wakeups: 0 Memory: 15.5 GiB used: 6.99 GiB (45.1%) 
           Init: systemd v: 247 Compilers: gcc: 10.2.0 clang: 11.1.0 Packages: pacman: 1556 
           lib: 452 Shell: fish (sudo) v: 3.1.2 default: Bash v: 5.1.4 running in: alacritty 
           inxi: 3.3.01 

Sure. There could be several reasons. First, tell us everything you have read, forum-wise, Googled, etc. Then tell us what you have tried, the results, and what you have not done. Please be detailed--we do not want to get into guessing games. The onus is on you to do the research.

No. It's your machine. By the time you have done your full research, if the problem still persists we may have some suggestions. But we don't guarantee the work--you're the "mechanic."

And don't forget to tell us what works.

regards

4 Likes

xD

Well, I tried what I described:

  • monitoring the resources consumption (everything fine there as far as I am concerned. Fine -> nothing gets even close to 80%)
  • checking the journal (also nothing completely unusually as far as I know, but I provided link because maybe someone knows better)
  • checking out if by any chance leftover of docker volumes do not take too much space (only 2 gigs atm)
  • checking out if journal logs do not take too much space (no they don't)

Anyway, of course, I can solve the problem by searching a freaking google. Enough hours there and you will find everything, but it's not fun, at least for me. And if I can ask some knowledgeable people to give me a quick list of commands to run which could potentially provide good insight, then that's what I believe the forums are for...

Well, I'm only speaking for me..but..I do agree with Cooter above, it's your machine, you know what you've done with it, I can't touch it and try things.
And, what are you paying me per hour to diagnose your car engine (or computer)? Not quite sure why YOUR time is more valuable than mine (re: google).
I'm not really trying to be rude (you'd know if I were).
With that said, anyone else that wants is quite welcome to point you in directions.

1 Like

Tbh. your first answer Dbbaron already provided some insight which is welcome (swap uuids, dns resolutions) though these are things I will need to research separately.

My point is: if someone had a similar problem or knows which commands/tools can help to diagnose it, then listing them is in my opinion is a good help. I do not expect anyone to try to find me a solution or direction if they don't have it in their brain's ram easily available.

1 Like

Too many people expect that other owe them solutions :slight_smile:

2 Likes

If you say so... Are you sure????
Maybe some performance tweaks, auto-cpufreq etc., hold your resources down.
Interestingly no zram swap is used, but maybe incidentally you got info while at idle.

Logged errors include Xorg related crashes/failures, that have domino effect on SDDM and kWin.

Is your system properly updated?
Recheck your mirrors.

Set some traps... :laughing:

2 Likes

And try different kernels.

Cpu/Mem consumption: Am I sure? Well, not really. I checked the htop/sysGuard for some time when I experiened "slugishness" and I haven't witnessed anything out of norm, but it might be that, I am not glancing at the appropriate time.
I will set up some script to gather the data for a longer period of time.
Xorg crashes... Well will need to look further into that.

Is my system updated: Yes, I update rather regullarly.

Try other kernel: Ok will swap to zen, and see how it goes.

Docker and subvolumes: I have read that article, but I didn't accumuleted even close to the amount of data that the author had from subvolumes, so I don't think it's the cause. But he also reported the system lags, so maybe there is some common ground there after all. Anyway, will try the other options first.

You can try this:

To test if the Garuda performance-tweaks are causing problems on your system you may want to try masking the following services one at a time. After stopping/disabling/masking any service you should reload all services with the following command:

sytemctl daemon-reload

In some instances you may also need to reboot to fully change the services state as reloading may not be sufficient in some cases. After rebooting test your system for improvements.

Disable (and stop) the auto-cpufreq.service :

systemctl disable --now auto-cpufreq.service

Mask the auto-cpufreq.service :

systemctl mask auto-cpufreq.service 

Disable (and stop) the prelockd.service :

systemctl disable --now prelockd.service

Mask the prelockd.service :

systemctl mask prelockd.service

Disable (and stop) the memavaild.service :

systemctl disable --now memavaild.service

Mask the memavaild.service :

systemctl mask memavaild.service 

It is probably best to reboot after changing the states of these services, then test your system for improvements. If you wish to reactivate the service(s) after troubleshooting, repeat the command(s) substituting "unmask" in place of "mask" and "enable" in place of "disable". The services may be re-enabled if the performance-tweaks package is updated during a system upgrade.

See the Archwiki if you wish to find further information regarding enabling, disabling, or masking systemd services:

https://wiki.archlinux.org/index.php/systemd


3 Likes

OK. That explains all the masking/unmasking. Thanks. :slight_smile:

1 Like

Didn't have time yet to run the more complex troubleshooting, but just would like to update here that changing to the Linux Zen Kernel as c00ter suggested, at least for now vastly improved the pc performance.

No more super sluggish episodes experienced.
I will post another updated here in after I run some analysis of logs and perfomance-tweaks mentioned by tbg.

Thank you very much for assistance guys :smiley:

4 Likes

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.