Which package is beeing updated during slowdown ?
When the package Nvidia is beeing updated, then this takes some time.
He doesn’t have Nvidia, and he says it does it with whatever package, but yeah knowing what package it gets stuck on is still good.
The slowdown can happen at any package: is unpredictable, a totally random thing.
And yes: I don’t have Nvidia 
Then start “top” on console and check the status of the computer during update.
I performs the updates from TTY2; would be ok, in the meantime, switch to another TTY and run top at the same time?
1 Like
Yes, you can do that.
A thought: since I live in the middle Europe, I update my mirrors by executing pacman-mirrors --country Italy,Spain,Germany,Netherlands,France,Austria and since the update of April 18, 2021, I performs the updates the same day of the announcements; could be, maybe, that some package could be in some way partially corrupted?
I repeat: the download process of packages have no issue (so, also during huge system update can be downloaded GB of packages, so there also GB write to disk here), is fast as always: the problem occurs only during the installation process.
In anyway: on the next stable update I will update on live USB using chroot, I plan to do the following, in the Terminal of live USB system:
manjaro-chroot -asudo pacman-mirrors -c allsudo pacman -Syyu
Is the right way, on chroot in live USB?
Also considering that on my system I also have other DKMS modules, not only the ones of VirtualBox, but I also have rtl88x2bu, rtl8814au and v4l2loopback (and I repeat: these modules are quickly compiled/installed, no slowdowns on them); I ask if they will be properly compiled/installed on chroot in live system.
Furthermore, in the config file /etc/pacman.conf I have some packages to exclude: will be, this config file, honored in chroot in live system?
He
He did hijacked my thread. That is fine I was done with it and may need a new one. Cheers
I applied the actual Stable Branch update:
I booted Manjaro USB and I executed the above (quoted) commands, and…
It took 5 minutes to do everything! No slowdowns at all!
So… Something is wrong on my system.
No hardware failures.
@linux-aarhus and also @Keruskerfuerst :
what do you think about?
How old is your installation of the OS ?
Can you post fdisk -l ?
Since 19 February 2019, and the pacman slowdowns start to occurs since the stable update of 18 April 2021, so one month ago.
Disk /dev/sdb: 232,89 GiB, 250059350016 bytes, 488397168 sectors
Disk model: CT250MX500SSD1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x6a9bdb86
Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 488396799 488394752 232,9G 83 Linux
Disk /dev/sda: 465,76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Samsung SSD 860
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x812a6590
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 976771071 976769024 465,8G 83 Linux
/dev/sda1 is where Manjaro is installed.
In anyway: the slowdown doesn’t occurs elsewhere.
I would perform a new installation:
- /boot/efi 100 MB vfat
- /boot 1GB ext4
- swap ~16GB
- /(root) 100 GB ext4
- /home the rest
And: you have no swap partition.
Do you have a swap file ?
So it’s safe to assume the problem lies within the installation itself (configuration, boot/module parameters, schedulers, power settings like tlp etc).
My system is set to MBR, not UEFI.
I don’t have any swap (no partition nor file).
I would prefer to identify the problem instead of reinstalling everything, since for the rest, I repeat, the system is fine.
I will accurately check my personal logs (I keep track of every change) to see if since 18 April 2021 i changed something which could have interfered with pacman.
In the meantime while I wait for the next stable update, do you have some suggestions, like, eg, some test to performs?
Eg: the SSD seems fine; I also tried to copy, from an external USB 3 HDD, huge files into the SSD, and is went ok.
As I/O scheduler I have mq-deadline; there I made some editing (placed in /etc/udev/rules.d/60-scheduler.rules) which contains:
ACTION=="add|change", KERNEL=="sd[a-b]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"
ACTION=="add|change", KERNEL=="sda", ATTR{queue/rotational}=="0", ATTR{queue/iosched/fifo_batch}="16"
ACTION=="add|change", KERNEL=="sda", ATTR{queue/rotational}=="0", ATTR{queue/iosched/writes_starved}="4"
ACTION=="add|change", KERNEL=="sda", ATTR{queue/rotational}=="0", ATTR{queue/iosched/write_expire}="500"
ACTION=="add|change", KERNEL=="sda", ATTR{queue/rotational}=="0", ATTR{queue/iosched/read_expire}="50"
ACTION=="add|change", KERNEL=="sda", ATTR{queue/rotational}=="0", ATTR{queue/nr_requests}="64"
ACTION=="add|change", KERNEL=="sd[a-b]", ATTR{queue/rotational}=="0", ATTR{queue/read_ahead_kb}="256"
ACTION=="add|change", KERNEL=="sd[a-b]", ATTR{queue/rotational}=="0", ATTR{queue/iostats}="0"
tlp is set to max performances when on AC (I performs the updates on AC), eg, output of tlp-stat -p:
+++ Processor
CPU model = Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver = intel_pstate
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor = performance
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors = performance powersave
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq = 1200000 [kHz]
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq = 3100000 [kHz]
/sys/devices/system/cpu/cpu1/cpufreq/scaling_driver = intel_pstate
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor = performance
/sys/devices/system/cpu/cpu1/cpufreq/scaling_available_governors = performance powersave
/sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq = 1200000 [kHz]
/sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq = 3100000 [kHz]
/sys/devices/system/cpu/cpu2/cpufreq/scaling_driver = intel_pstate
/sys/devices/system/cpu/cpu2/cpufreq/scaling_governor = performance
/sys/devices/system/cpu/cpu2/cpufreq/scaling_available_governors = performance powersave
/sys/devices/system/cpu/cpu2/cpufreq/scaling_min_freq = 1200000 [kHz]
/sys/devices/system/cpu/cpu2/cpufreq/scaling_max_freq = 3100000 [kHz]
/sys/devices/system/cpu/cpu3/cpufreq/scaling_driver = intel_pstate
/sys/devices/system/cpu/cpu3/cpufreq/scaling_governor = performance
/sys/devices/system/cpu/cpu3/cpufreq/scaling_available_governors = performance powersave
/sys/devices/system/cpu/cpu3/cpufreq/scaling_min_freq = 1200000 [kHz]
/sys/devices/system/cpu/cpu3/cpufreq/scaling_max_freq = 3100000 [kHz]
/sys/devices/system/cpu/intel_pstate/min_perf_pct = 100 [%]
/sys/devices/system/cpu/intel_pstate/max_perf_pct = 100 [%]
/sys/devices/system/cpu/intel_pstate/no_turbo = 0
/sys/devices/system/cpu/intel_pstate/turbo_pct = 31 [%]
/sys/devices/system/cpu/intel_pstate/num_pstates = 20
x86_energy_perf_policy.cpu0 = performance
x86_energy_perf_policy.cpu1 = performance
x86_energy_perf_policy.cpu2 = performance
x86_energy_perf_policy.cpu3 = performance
/sys/module/workqueue/parameters/power_efficient = Y
/proc/sys/kernel/nmi_watchdog = 0
+++ Undervolting
PHC kernel not available.
The system is blazingly fast: and I have no problem with no swap: I can saturate the RAM without hiccups:
Private + Shared = RAM used Program
380.0 KiB + 23.5 KiB = 403.5 KiB incrond
396.0 KiB + 85.5 KiB = 481.5 KiB rtkit-daemon
896.0 KiB + 29.5 KiB = 925.5 KiB dconf-service
1.0 MiB + 34.5 KiB = 1.1 MiB xfconfd
1.0 MiB + 30.5 KiB = 1.1 MiB gvfsd-fuse
1.1 MiB + 71.5 KiB = 1.1 MiB gvfsd
1.0 MiB + 107.5 KiB = 1.1 MiB rngd
1.3 MiB + 95.5 KiB = 1.3 MiB gvfsd-trash
1.3 MiB + 97.5 KiB = 1.4 MiB gvfsd-dnssd
1.3 MiB + 79.5 KiB = 1.4 MiB gvfsd-computer
1.3 MiB + 86.5 KiB = 1.4 MiB gvfsd-network
1.3 MiB + 108.5 KiB = 1.4 MiB accounts-daemon
1.3 MiB + 577.5 KiB = 1.9 MiB systemd-logind
1.8 MiB + 149.5 KiB = 1.9 MiB thermald
1.8 MiB + 100.5 KiB = 1.9 MiB gvfsd-http
2.3 MiB + 258.5 KiB = 2.6 MiB gnome-keyring-daemon
2.4 MiB + 145.5 KiB = 2.6 MiB picom
2.1 MiB + 515.5 KiB = 2.6 MiB systemd-udevd
2.0 MiB + 662.5 KiB = 2.6 MiB systemd-coredump
2.2 MiB + 537.5 KiB = 2.7 MiB gvfs-udisks2-volume-monitor
2.4 MiB + 384.5 KiB = 2.7 MiB upowerd
2.6 MiB + 102.5 KiB = 2.7 MiB gvfsd-metadata
2.8 MiB + 30.5 KiB = 2.9 MiB xbindkeys
2.5 MiB + 396.5 KiB = 2.9 MiB sudo
3.2 MiB + 252.5 KiB = 3.4 MiB NetworkManager
3.0 MiB + 702.5 KiB = 3.6 MiB systemd-journald
3.3 MiB + 649.0 KiB = 4.0 MiB dbus-daemon (2)
3.5 MiB + 572.0 KiB = 4.0 MiB lightdm (2)
3.9 MiB + 264.5 KiB = 4.1 MiB wpa_supplicant
4.8 MiB + 584.5 KiB = 5.4 MiB udisksd
5.1 MiB + 1.5 MiB = 6.6 MiB script-fu
7.1 MiB + 359.5 KiB = 7.4 MiB xfce4-power-manager
7.0 MiB + 494.5 KiB = 7.5 MiB xfce4-volumed-pulse
7.1 MiB + 506.5 KiB = 7.6 MiB panel-19-systra
7.7 MiB + 404.5 KiB = 8.1 MiB xfce4-session
7.9 MiB + 446.5 KiB = 8.3 MiB xfsettingsd
8.0 MiB + 798.5 KiB = 8.8 MiB python3.9
5.2 MiB + 3.8 MiB = 9.0 MiB systemd (3)
9.4 MiB + 594.5 KiB = 10.0 MiB pulseaudio
9.6 MiB + 536.5 KiB = 10.1 MiB xfce4-screensaver
9.7 MiB + 1.0 MiB = 10.7 MiB xfce4-notifyd
10.4 MiB + 1.4 MiB = 11.8 MiB polkit-gnome-authentication-agent-1
11.4 MiB + 1.2 MiB = 12.5 MiB nm-applet
12.8 MiB + 1.5 MiB = 14.3 MiB xfwm4
12.7 MiB + 1.6 MiB = 14.3 MiB conky (3)
13.4 MiB + 1.4 MiB = 14.8 MiB xfce4-panel
12.0 MiB + 3.4 MiB = 15.4 MiB tumblerd
15.8 MiB + 225.5 KiB = 16.0 MiB polkitd
13.9 MiB + 2.3 MiB = 16.3 MiB xfce4-terminal
15.7 MiB + 1.6 MiB = 17.2 MiB panel-9-docklik
15.9 MiB + 2.8 MiB = 18.7 MiB panel-4-whisker
23.0 MiB + 246.5 KiB = 23.2 MiB plugin_host
29.2 MiB + 1.4 MiB = 30.6 MiB bash (2)
27.9 MiB + 3.2 MiB = 31.1 MiB xfdesktop
30.7 MiB + 2.8 MiB = 33.5 MiB kdeconnectd
32.8 MiB + 3.4 MiB = 36.2 MiB Thunar
35.5 MiB + 1.3 MiB = 36.7 MiB autokey-gtk
38.5 MiB + 1.0 MiB = 39.5 MiB panel-15-power-
40.9 MiB + 1.5 MiB = 42.4 MiB gedit
64.6 MiB + 19.5 KiB = 64.6 MiB dnscrypt-proxy
48.0 MiB + 20.9 MiB = 68.9 MiB Xorg
238.0 MiB + 8.0 MiB = 246.0 MiB subl3
548.1 MiB + 94.8 MiB = 642.8 MiB firefox (7)
4.4 GiB + 6.5 MiB = 4.4 GiB XnView
5.0 GiB + 9.8 MiB = 5.0 GiB gimp-2.10
---------------------------------
10.9 GiB
=================================
total used free shared buff/cache available
Mem: 15Gi 10Gi 167Mi 512Mi 4,7Gi 4,0Gi
Swap: 0B 0B 0B
If you can reproduce/provoke/test the slowdowns without waiting for big updates, you can try to remove all twaeks to get your system as close as possible to the state of the live usb (which showed no problems).
If this helps, then re-apply the tweaks to determine the culprit.
I’ve no indicatation that any of the following points contribute to the problem, just throwing things around to see if something sticks:
- Does the live usb use another kernel (version) than the installed system? If yes, then try with the same kernel.
- turn off
tlpentirely (just for testing) - Is thermald installed+enabled on your system and tries to throttle at some point?
- Check if the scaling_driver/governor are different in live usb (perhaps
schedutil?), possibly switch your system:
- re-visit io-scheduler
Those seem very specific, do you know why you added those? Do you see any improvement (or negative effect) with those disabled?
Yep: is installed and will throttle the CPU when it reach 56 celsius degree, which happen only when I do intensive CPU tasks (eg during package compilation); it throttle the CPU by liimiting the max (turbo) frequency from 3.10Ghz to 2.50Ghz; and in anyway, in the BIOS of my laptop, I set the fan always on (which normally is very silent: it increase when the CPU reach about 65 celsius degree).
Yeah, I also know what they do (I am against to apply random values taken from internet ) because I study the official documentation:
https://www.kernel.org/doc/html/latest/block/deadline-iosched.html
https://www.kernel.org/doc/html/latest//scheduler/sched-deadline.html
And the more accurate:
https://www.kernel.org/doc/Documentation/block/deadline-iosched.txt
I tweaked it to balance between low latency and increased throughput;
The main differences which I blantly note, eg, are:
Faster startup time: the average startup time without I/O tweaks, was of 2.500s (average, so could oscillate between, eg, 2.700s and 2.300); currently instead the startup time is around 2.100s, mostly at 2.090s; atm, the last from systemd-analyze is:
Startup finished in 872ms (kernel) + 716ms (initrd) + 490ms (userspace) = 2.079s
graphical.target reached after 489ms in userspace
But obvioulsy not only this “minor” differences; another thing that I notice, eg, (mainly thanks to increased read_ahead_kb value ) is in opening big files: eg here I have a 4.3GB *.tiff image picture file; with these I/O tweaks it take about 5 seconds to be opened; without tweaks (not only them to the I/O scheduler) it used to take about the double of the time.
In anyway at the next update I will try to exclude not only the I/O tweaks but also the others which you suggested me 
1 Like
This time, in the current stable update [Stable Update] 2021-06-07 - Kernels, Perl, Haskell, Tesseract, Cutefish, KDE, Nvidia, I have been “brave”. I had time to follow all the process of pacman; I had all the “instruments” to investigate the slodown: top, htop, iotop, nethogs and fatrace. But this time, they haven’t been needed.
Why?
Because in such stable update, the upgrading process has been quick and smooth as before… And I have no clue. 
Furthermore, I faced an improvement: from the BIOS screen to the login screen the time has been decreased: using a stopwatch I counted five seconds, never like before…
And the current output of systemd-analyze is:
Startup finished in 879ms (kernel) + 687ms (initrd) + 494ms (userspace) = 2.061s
graphical.target reached after 493ms in userspace
Again: I have no clue.
But I would retain this discussion open; I don’t know where the resolution relies.
I also performed the [Stable Update] 2021-07-13 on my system (not from live usb) without any issue and I discovered where the problem resided: in CPU’s throttling, and I feel stupid
I found that in /etc/thermald/thermal-conf.xml config file, I had set the temperature to 50 celsius degrees, probably for testing purposes…
By set it again to 65 celsius degree, or by stopping thermald.service, the update processes, so, had gone fine as should be.
Furthermore, under the laptop’s stand, I installed three fans, to ensure to have the laptop more cool in terms of temperature.
Case closed
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.