Troubleshooting Installed Packages:
Always be sure to note the exact time and date when a performance issue first appears. Knowing the date of the first occurrence can be crucial in helping to narrow down the package(s) responsible for causing the problem. If you update on a daily basis and know when the issue first started finding the offending package should be relatively simple. This is because the list of newly installed packages should be small, and therefore far easier to troubleshoot. If you update frequently, you should have a reasonably short list of packages to investigate. if you haven’t updated for a month the package list will be massive, and the package responsible will be far more difficult to track down.
Software troubleshooting often involves removing or downgrading package installations that coincided with the time your issue first started to appear. Check your /var/log/pacman.log for packages installed just before the time that your issue first presented. The following command will help make it easier to identify the list of potential problem packages, (if you know the exact date the update was performed):
cat /var/log/pacman.log | grep '2023-11-30' | grep -E 'installed|upgraded|removed
You must substitute the date you performed the problematic update for the date of Nov 30th, 2023 in the above command.
Drivers or firmware packages updated around the time the problem began are prime candidates for causing major issues. Downgrade any driver or firmware packages that were updated recently to an older version. The video driver not being suitable for the video card in use is one of the most common causes of display abnormalities. Selectively downgrade one package at a time, (starting with the most likely first). Hopefully through the process of elimination you can identify fairly quickly exactly which package update was responsible for creating your issue. It is best to reboot after downgrading a package, (especially if a driver or firmware downgrade was performed).
If you you have a fairly extensive list of packages that you suspect, be sure to search thoroughly online for recent bug reports that sound similar to what you are experiencing. If you identify a package that may be problematic, then test your suspicion out by downgrading that package to the previous version. If a downgrade solves your problem, then you will need to hold the package version to prevent the problematic version from being automatically reinstalled during your next update. Any bug of a serious nature you discover should be reported to the upstream project to hopefully get a quick resolution. Hold the offending package at the old version for a week or two and then again test out the newer version to see if a fix has been applied.
When experiencing performance issues, It can help to keep a system monitoring utility such as htop continuously running to keep an eye on your resource usage. Hopefully this can help identify if any specific program or process may be contributing to your issue. Track how much memory is in use, and try to identify any process that exhibits constantly rising memory usage. This is indicative of a program with a memory leak that will eventually crash your system if it not prevented from consuming all your available RAM. If the offending package/program is non-essential, stop using it, or uninstall it. If you just can’t do without this problematic software, you will need to file a bug report to help the upstream software developers resolve the issue in a timely manner.
An often overlooked source of system instability is the addition of Gnome extensions or Plasma widgets. If you have added any extensions or widgets then be sure to remove these addons to eliminate them from the list of possibilities. I once had a memory leak that totally baffled me as the leaking process was not identifiable with a monitoring utility. I’d almost given up on identifying the leak when I remembered I’d installed a few widgets a while back. As soon I removed these recently added widgets my problem went away, so don’t forget about these tiny programs as they have the potential to cause big problems.
A user requested I add Baloo (KDE’s search engine) to the list of problematic software. Baloo can at times consume excessive amounts of CPU or RAM. The Garuda defaults for Baloo were changed quite some time ago, so this hasn’t been much of a problem of late. However, if you enable full content indexing of all drives (especially very large storage drives) this can impact performance quite dramatically at times. If your machine is older with limited RAM Baloo can at times almost grind your system to a halt during heavy indexing operations. KDE will not permit uninstallation of Baloo, but it can be disabled so that it will not negatively impact your performance. See the KDE Baloo troubleshooting guide for further details:
Full system reinstallation (in stages):
If your issue only started recently and was not present when testing in a live boot environment, then a recent update to a program, driver, firmware, bios, or kernel has likely caused this. If your issue started a while ago, but you have no idea exactly when it began, a reinstallation may help identify the package(s) causing your problems. If you only just installed your system, then following the instructions below would likely be profitless.
If you feel a reinstallation of Garuda is warranted, then perform the installation in stages to help narrow down any package(s) possibly causing your issue. First perform an offline install with no internet connection. Once your installation is complete, do not install any extra packages or update your system just yet. Stress your system to determine with 100% certainty if the freezes are no longer happening. Once this has been determined, do your system updates.
If the freezes start again after updating, (when good before), then you will need to try and figure out which package(s) in the update list are the trigger. Be sure to allow plenty of time after each stage to ascertain whether your freezing issue returns. If there are still no freezes after updating your system, then start slowly installing your normal software only one package at at a time, (AUR packages last). Stress your system after each new package installation to determine if freezing occurs. If the system freezes are triggered after installing a particular package then you have likely located the cause of your problem.
Further software related suggestions:
Try disabling hardware acceleration in your web browser(s), as this has been known to cause freezing with some hardware.
Try creating a new user account, If the new user account is problem free, then the issue originates in your original user’s home settings.
Power saving software such as tlp can sometimes contribute to freezing, so you may want to temporarily disable or uninstall it.
Uninstall or disable all Plasma widgets (plasmoids) that you installed yourself.
Uninstall or disable all Gnome extensions you’ve installed yourself?
Using an aggressive system cleaner such as Bleach Bit can result in system instability if great care is not taken during cleaning operations.
Firefox has been well known for issues relating to memory leaks or causing freezes in the past. Install and use an alternate browser to see if your system stability improves.
Questions relating to your installed software:
Is your system fully updated?
Have you tried resetting your default configs with Garuda Assistant?
Have you tried creating a new user account?
Did you install any packages from the AUR around the time when the issue began?
Did you notice any driver package updates around the time when your issue began?
Was there a major update to your Desktop Environment about the same time your issue began?
Are all your packages from the AUR fully updated?
Have you checked upstream for any outstanding bug reports in any software you think could be responsible for your issue?X11 vs Wayland:
I have recently seen an increasing trend that I thought I’d better add to my list of causes for poor system performance. As installation and usage of Wayland has become more commonplace, reports of poor system performance have also increased. The Wayland display server has made great strides, and will likely become the default windowing system on many Linux machines in the near future. However, Wayland still has its share of bugs and although much improved it still causes issues on some systems, (more-so if using the KDE desktop).
The following issue has affected systems that are using Nvidia graphics adapters on KDE installs running Wayland. are missing the kernel parameter for Direct Rendering Manager (DRM)
nvidia-drm.modeset=1
Needs to be added for Nvidia in a Wayland session to work correctly.
Therefore, my suggestion would be to switch to an X11 session if encountering any performance issues when using Wayland, (if Wayland is your default). Conversely, switching to a Wayland session may in some cases of poor system performance result in a great improvement. To sum things up, make sure you test out both types of sessions if experiencing performance issues using either Wayland or X11.