[SOLVED] Arch running really slow

Gravel · 2022-06-01 20:52:25

Hello everyone,
Ever since I installed Arch I noticed it was not as fast as I expected it to be, and it has come to the point that it frequently staggers and freezes on seemingly mundane things such as loading programs or even displaying things such as latte dock (KDE taskbar widget), especially when multiple programs are open (although still way below my computer's threshold)
On top of that, the boot times are also not great, taking up to 3 minutes to fully boot up the system, when my dual booted windows system takes 4 seconds taking into account password input. (It is to note however, that my windows install is on an SSD and my arch one is on an HDD and tbh if that's enough to reduce boot time by 2:56 then I will probably consider buying an SSD for arch lol)

I also know that nvidia drivers don't really get along with linux itself but I'm unsure if that alone is causing all the staggering so better be safe.

Currently running 5.17.6-arch1-1, although it has been happening since I installed it

Specs:

CPU: Intel i7-9700K (8) @ 4.900GHz
GPU: NVIDIA GeForce RTX 2070 SUPER
Memory: 15933MiB

hdparm output: 502 MB in 3.00 seconds = 167.23 MB/sec
GLX Direct rendering: Yes
htop output

Any input is greatly appreciated :)

Last edited by Gravel (2022-06-11 18:42:06)

Trilby · 2022-06-01 21:00:24

Post the output of `systemd analyze critical-chain` to diagnose the boot time issues. As for the only other thing we actually have data on, if that image is representative, then plasmashell is clearly fubar. A journal log (linked to in a file sharing site) would likely help, along with any plasmashell-specific logs.

Also note that that image is too large for the forums - please remove it and post a link to it if you think it's relevant. But photos of text are not actually relevant, text is.

Last edited by Trilby (2022-06-01 21:01:03)

Gravel · 2022-06-01 21:19:12

Critical chain output:

graphical.target @37.778s
└─multi-user.target @37.777s
  └─systemd-user-sessions.service @37.494s +11ms
    └─network.target @37.493s
      └─NetworkManager.service @7.616s +477ms
        └─dbus.service @6.927s +683ms
          └─basic.target @6.923s
            └─sockets.target @6.920s
              └─dbus.socket @6.918s
                └─sysinit.target @6.898s
                  └─systemd-update-utmp.service @6.843s +51ms
                    └─systemd-tmpfiles-setup.service @6.731s +108ms
                      └─local-fs.target @6.708s
                        └─home.mount @6.625s +80ms
                          └─systemd-fsck@dev-disk-by\x2duuid-cf569752\x2d50ae\x2d4500\x2dbfb6\x2d234a5fae8154.service @5.818s +788ms
                            └─dev-disk-by\x2duuid-cf569752\x2d50ae\x2d4500\x2dbfb6\x2d234a5fae8154.device @5.814s

Journalctl output

Also, understood about the images. Hope this is better then

seth · 2022-06-02 05:39:58

The journal is truncated,

sudo journalctl -b > /tmp/journal.txt

Also post the xorg log, https://wiki.archlinux.org/title/Xorg#General

What we already can say is that the boot is stalled by the network:

    └─network.target @37.493s
      └─NetworkManager.service @7.616s +477ms

Gravel · 2022-06-02 15:17:53

Journal no2: https://0x0.st/oBnd.txt
Xorg log: https://0x0.st/oBnn.log

seth wrote:

What we already can say is that the boot is stalled by the network:
    └─network.target @37.493s
      └─NetworkManager.service @7.616s +477ms

Indeed, and thanks to that I also found out that dhcpd takes an unusually long amount of time to load up (shown on startup logs), then fails, and tells me to run systemctl status dhcpd@enp6s0.service:

$ systemctl status dhcpcd@enp6s0.service 
× dhcpcd@enp6s0.service - dhcpcd on enp6s0
     Loaded: loaded (/usr/lib/systemd/system/dhcpcd@.service; enabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Thu 2022-06-02 16:49:15 UTC; 23min ago
    Process: 474 ExecStart=/usr/bin/dhcpcd -q -w enp6s0 (code=exited, status=1/FAILURE)
        CPU: 73ms

Jun 02 16:48:49 archon dhcpcd[478]: enp6s0: soliciting a DHCP lease
Jun 02 16:48:49 archon dhcpcd[478]: enp6s0: soliciting an IPv6 router
Jun 02 16:49:02 archon dhcpcd[478]: enp6s0: no IPv6 Routers available
Jun 02 16:49:15 archon dhcpcd[478]: timed out
Jun 02 16:49:15 archon dhcpcd[474]: timed out
Jun 02 16:49:15 archon systemd[1]: dhcpcd@enp6s0.service: Control process exited, code=exited, status=1/FAILURE
Jun 02 16:49:15 archon systemd[1]: dhcpcd@enp6s0.service: Failed with result 'exit-code'.
Jun 02 16:49:15 archon systemd[1]: Failed to start dhcpcd on enp6s0.

And despite timing out and failing to start, the system is connected to the internet when the GUI is usable nonetheless:

$ systemctl status network.target 
● network.target - Network
     Loaded: loaded (/usr/lib/systemd/system/network.target; static)
     Active: active since Thu 2022-06-02 16:49:15 UTC; 23min ago
      Until: Thu 2022-06-02 16:49:15 UTC; 23min ago
       Docs: man:systemd.special(7)
             https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget

Jun 02 16:49:15 archon systemd[1]: Reached target Network.

I'm probably missing out on something but I'm not sure what to do now

seth · 2022-06-02 15:52:47

You're running on the nvidia driver and there's no obvious issue w/ that (eg. you might have been using software rendering to explain the CPU overload)

Running networkmanager AND dhcpcd is bad to begin with.

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

In general, pick one, disable all others. If there's only one wired NIC, dhcpcd will do and you don't need NM at all.

Gravel · 2022-06-02 17:33:13

Welp you were completely right, I didn't even notice that only one of them were needed...

After testing both, surprisingly NW ended up being the faster one so I ended up disabling dhcpcd, but even after the substantial improvement that it made removing it I feel like there's still more room for improvement left:

graphical.target @27.453s
└─multi-user.target @27.451s
  └─systemd-user-sessions.service @27.025s +14ms
    └─network.target @27.021s
      └─NetworkManager.service @26.519s +499ms
        └─dbus.service @22.211s +4.302s
          └─basic.target @22.207s
            └─sockets.target @22.206s
              └─dbus.socket @22.205s
                └─sysinit.target @22.140s
                  └─systemd-update-utmp.service @21.954s +184ms
                    └─systemd-tmpfiles-setup.service @21.742s +208ms
                      └─local-fs.target @21.632s
                        └─home.mount @21.461s +171ms
                          └─systemd-fsck@dev-disk-by\x2duuid-cf569752\x2d50ae\x2d4500\x2dbfb6\x2d234a5fae8154.service @5.623s +15.789s
                            └─dev-disk-by\x2duuid-cf569752\x2d50ae\x2d4500\x2dbfb6\x2d234a5fae8154.device @5.621s

Startup finished in 8.089s (firmware) + 678ms (loader) + 3.374s (kernel) + 27.454s (userspace) = 39.597s 
graphical.target reached after 27.453s in userspace.

The biggest spikes are now home.mount followed up by NW, could home.mount be optimized by an SSD?

And on the other side of my original post, any indices on why arch staggers when multiple programs are open? I can notice the taskbar and menus & programs stuttering and freezing when just 3-4 programs are open, and sys diagnosis show the hardware to be way below its maximum capacity (when said stuttering happens).

Thanks as always

schard · 2022-06-02 19:02:09

The mount time for home is unusually long. Please run a smartctl long test and post the results.

Gravel · 2022-06-02 22:13:44

Here it is:

smartctl 7.3 2022-02-28 r5338 [x86_64-linux-5.18.1-arch1-1] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Blue
Device Model:     WDC WD10EZEX-60WN4A1
Serial Number:    WD-WCC6Y3RP4USY
LU WWN Device Id: 5 0014ee 2679fa1f2
Firmware Version: 03.01A03
User Capacity:    1,000,204,886,016 bytes [1.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database 7.3/5319
ATA Version is:   ACS-3 T13/2161-D revision 5
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Fri Jun  3 00:12:03 2022 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
See vendor-specific Attribute list for marginal Attributes.

General SMART Values:
Offline data collection status:  (0x82) Offline data collection activity
                                        was completed without error.
                                        Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever 
                                        been run.
Total time to complete Offline 
data collection:                (10920) seconds.
Offline data collection
capabilities:                    (0x5b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        No Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine 
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        ( 114) minutes.
SCT capabilities:              (0x303d) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   171   168   021    Pre-fail  Always       -       2408
  4 Start_Stop_Count        0x0032   097   097   000    Old_age   Always       -       3902
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002f   200   200   051    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   093   093   000    Old_age   Always       -       5340
 10 Spin_Retry_Count        0x0033   100   100   051    Pre-fail  Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       1006
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0033   100   100   097    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   054   033   040    Old_age   Always   In_the_past 46 (Min/Max 24/47 #5575)
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       131
193 Load_Cycle_Count        0x0032   196   196   000    Old_age   Always       -       13606
194 Temperature_Celsius     0x0022   097   076   000    Old_age   Always       -       46
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%      5339         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

seth · 2022-06-03 04:58:29

                        └─home.mount @21.461s +171ms
                          └─systemd-fsck@dev-disk-by\x2duuid-cf569752\x2d50ae\x2d4500\x2dbfb6\x2d234a5fae8154.service @5.623s +15.789s

Home actually mounts instantly, but there's forced fsck on one of the partitions.
If that happens constantly, something doesn't properly umount.

lsblk -f

From your previous htop, plasmashell and kwin take a lot of CPU - do you have similar issues w/ an openbox session (no plasma at all)?
The combination of both would suggest that maybe some plasma widget goes into a repaint frenzy (inducing the load on the compositor kwin) - does the kwin load drop when you suspend the compositor (SHIFT+Alt+F12)?

Edit: the disk looks unsuspicious

Last edited by seth (2022-06-03 04:58:48)

Gravel · 2022-06-04 10:52:26

seth wrote:

From your previous htop, plasmashell and kwin take a lot of CPU - do you have similar issues w/ an openbox session (no plasma at all)?

Nope, I just booted up an openbox session and idle CPU usage is 0%

seth wrote:

The combination of both would suggest that maybe some plasma widget goes into a repaint frenzy (inducing the load on the compositor kwin) - does the kwin load drop when you suspend the compositor (SHIFT+Alt+F12)?

No once again, after suspending the compositor and removing widgets or other things that could be causing issues, the drop was of about a 5%, and the consistent 10% spikes canceled that out so no diff, still using 50-60% cpu

seth · 2022-06-04 14:44:28

widgets or other things that could be causing issues

What specifically? Because in the past the CPU/RAM/NET monitoring widgets were prone to cause plasma CPU load (and since openbox is fine, it's pretty clear that it's plasma)

Does plasmashell show equally high CPU load w/ a fresh user account (ie. the plasma default config)?

Gravel · 2022-06-06 14:42:48

Actually, I think I've found the cause of the problem:

Actually, it turns out that media reproduction was causing such spikes, with htop going from ~15% to ~60% when playing a video in firefox, with each consecutive media being played adding around a ~10-20% more to the load, and spiking up to 40% when starting playback.
And honestly, since I always have music on when using my computer, I never really even considered that as a posibility sooo yeah...

Htop (youtube paused): https://imgur.com/U4IjAAQ
Htop (with media): https://imgur.com/OM88dLb

Any tips on how to improve performance on this?

seth · 2022-06-06 14:55:20

https://wiki.archlinux.org/title/Firefo … celeration
https://wiki.archlinux.org/title/Music_Player_Daemon
https://aur.archlinux.org/packages/youtube-viewer
https://archlinux.org/packages/communit … s-youtube/
https://wiki.archlinux.org/title/Streamlink

icar · 2022-06-06 14:57:57

https://wiki.archlinux.org/title/Firefo … celeration

Edit: too slow.

For Nvidia, this works well in my case: https://github.com/elFarto/nvidia-vaapi-driver

Last edited by icar (2022-06-06 15:00:02)

Gravel · 2022-06-06 17:34:35

icar, could you spare some help on the nvidia-vaapi-driver? I must be doing something wrong, because nvidia-settings shows 0% video usage and nvidia-smi doesn't show any processes of type C

Here's what I did:

sudo modprobe nvidia_drm nvidia-drm.modeset=1

(This library requires that the nvidia_drm kernel module is configured with the parameter nvidia-drm.modeset=1)

I ran the following commands:

$ yay -S gstreamer-plugins-bad
$ cd /home/gravel/Downloads/nv-codec-headers-11.1.5.1/
$ make
$ cd /home/gravel/Downloads/nvidia-vaapi-driver-master/
$ meson setup build
# meson install -C build

(None of those gave any errors, and ofc, /gravel is personal user folder)

Then set all firefox options as:

media.ffmpeg.vaapi.enabled 	-> true 
media.rdd-ffmpeg.enabled 	-> true 
gfx.x11-egl.force-enabled 	-> true

Then ran:

$ LIBA_DRIVER_NAME=nvidia
$ MOZ_DISABLE_RDD_SANDBOX=1

And as far as I know, that should be all it takes to make it work, but as I said, no luck on it. Any indices?
(Firefox 101, X11)

progandy · 2022-06-06 17:46:58

sudo modprobe nvidia_drm nvidia-drm.modeset=1

Are you sure that works? Is it not necessary to boot with that parameter?
https://wiki.archlinux.org/title/NVIDIA … de_setting

Gravel · 2022-06-06 18:12:32

I also ran

$ nvidia_drm=nvidia-drm.modeset=1

and still not working

(lsmod output because I'm probably fucking something up)

nvidia_drm             73728  9
nvidia_uvm           2744320  0
nvidia_modeset       1425408  20 nvidia_drm
nvidia              45367296  1189 nvidia_uvm,nvidia_modeset

seth · 2022-06-06 19:41:47

I also ran

$ nvidia_drm=nvidia-drm.modeset=1
and still not working

That's not a command, but you assigned a meaningless shell variable and you cannot alter this w/ a command (at least it's not trivial to reload nvidia-drm) anyway.
https://wiki.archlinux.org/title/Kernel … odprobe.d/
https://wiki.archlinux.org/title/Kernel_parameters
In case the module is in the initramfs, you'll have to rebuild the initramfs if you went w/ a modprobe.d - for a quick test, a kernel parameter is simpler.

You can check "systool -vm nvidia_drm" but I don't think the parameter is exported so the output is likely useless.

Gravel · 2022-06-06 20:55:32

But /boot/loader/entries/arch.conf already has nvidia-drm.modeset=1, so that's probably not the issue then...

seth · 2022-06-06 21:03:38

cat /proc/cmdline

Depending on what kind of video you play, the codec might not be supported.
Check https://wiki.archlinux.org/title/Hardwa … ing_VA-API and the video codec (youtube has it in a right click menu "stats for nerds") and in doubt use an extension that forces youtube to use h264

Gravel · 2022-06-06 21:28:36

AV1 (Prior H264 forcing) - 0%
H264 (AVC1) - still 0%!

And indeed,

$ cat /proc/cmdline
initrd=\intel-ucode.img initrd=\initramfs-linux.img root=PARTUUID=382c7baa-c423-40bf-8eca-57510de1c922 rw nvidia-drm.modeset=1

I also double checked the installation files and it all seems to be there too:

$ ls /usr/include/ffnvcodec
dynlink_cuda.h  dynlink_cuviddec.h  dynlink_loader.h  dynlink_nvcuvid.h  nvEncodeAPI.h

vainfo o:

$ vainfo
vainfo: VA-API version: 1.14 (libva 2.14.0)
vainfo: Driver version: VA-API NVDEC driver
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      <unknown profile>               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileVP8Version0_3          : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointVLD

So I really don't know what I'm missing :(

Last edited by Gravel (2022-06-06 21:32:15)

seth · 2022-06-06 21:50:19

Then ran:

$ LIBA_DRIVER_NAME=nvidia
$ MOZ_DISABLE_RDD_SANDBOX=1

So w/ #18 this was probably literal and you probably don't export those environment variables to firefox.
https://wiki.archlinux.org/title/Environment_variables

Also it's "LIBVA_DRIVER_NAME", not "LIBA_DRIVER_NAME"

Gravel · 2022-06-06 22:24:49

Yup, mea culpa.
I added those flags to /etc/environment and indeed both nvidia-settings and nvidia-smi report video engine utilization and processes of type C+G respectively

However, CPU usage seems to be completely unaffected by that! Even with terminal yt viewers, /plasmashell still reports 60% cpu in htop, and it still disappears completely when I pause media playback.

seth · 2022-06-07 07:41:40

The load in your original htop image was in plasma & kwin and you said it's not a problem w/ openbox.
So this is most likely some plasma gadget (audio spectrum visualization?) that causes this.

Arch Linux

#1 2022-06-01 20:52:25

[SOLVED] Arch running really slow

Specs:

#2 2022-06-01 21:00:24

Re: [SOLVED] Arch running really slow

#3 2022-06-01 21:19:12

Re: [SOLVED] Arch running really slow

#4 2022-06-02 05:39:58

Re: [SOLVED] Arch running really slow

#5 2022-06-02 15:17:53

Re: [SOLVED] Arch running really slow

#6 2022-06-02 15:52:47

Re: [SOLVED] Arch running really slow

#7 2022-06-02 17:33:13

Re: [SOLVED] Arch running really slow

#8 2022-06-02 19:02:09

Re: [SOLVED] Arch running really slow

#9 2022-06-02 22:13:44

Re: [SOLVED] Arch running really slow

#10 2022-06-03 04:58:29

Re: [SOLVED] Arch running really slow

#11 2022-06-04 10:52:26

Re: [SOLVED] Arch running really slow

#12 2022-06-04 14:44:28

Re: [SOLVED] Arch running really slow

#13 2022-06-06 14:42:48

Re: [SOLVED] Arch running really slow

#14 2022-06-06 14:55:20

Re: [SOLVED] Arch running really slow

#15 2022-06-06 14:57:57

Re: [SOLVED] Arch running really slow

#16 2022-06-06 17:34:35

Re: [SOLVED] Arch running really slow

#17 2022-06-06 17:46:58

Re: [SOLVED] Arch running really slow

#18 2022-06-06 18:12:32

Re: [SOLVED] Arch running really slow

#19 2022-06-06 19:41:47

Re: [SOLVED] Arch running really slow

#20 2022-06-06 20:55:32

Re: [SOLVED] Arch running really slow

#21 2022-06-06 21:03:38

Re: [SOLVED] Arch running really slow

#22 2022-06-06 21:28:36

Re: [SOLVED] Arch running really slow

#23 2022-06-06 21:50:19

Re: [SOLVED] Arch running really slow

#24 2022-06-06 22:24:49

Re: [SOLVED] Arch running really slow

#25 2022-06-07 07:41:40

Re: [SOLVED] Arch running really slow

Board footer