Slow-downs while unpacking updated packages

Hi @linux-aarhus thank you for your reply.
As I promised I provide more information.
(but firstly, since I am sorry to have gone offtopic from this discussion, you or another moderator feel free to move my messages to another discussion).

I have Manjaro installed since February 2019 and I always performed system updates from TTY2; here I performs mirrors updated and then I execute sudo pacman -Syyu.

During these years whole system update process as always taken a maximum time of 15 minutes (I am on SSD) and I have a fast (100 Mbps) internet connection. Which is also reliable.

The issue which I described is related to the third step, when on console I read, eg, (83/88 upgrading virtualbox) - I take this one as example: as I’ve said, the slowdown can occurs on any package, is unpredictable: With slowdown I mean that the upgrading process, after a while, take a very long time, while the others previous (eg since 1/88 upgrading xxxx to 82/88 upgrading xxxx are quick and blazingly fast).

To summarize: since 1/88 upgrading xxxx to 82/88 upgrading xxxx the process is fast; then since 83/88 upgrading xxxx to 88/88 upgrading xxxx the process become very slow, and can occurs since any package, there is no pattern.

The execution of mkinitcpio and the building/upgrading of DKMS modules, instead, is fast as always, after the slowdown process of pacman.
On the other post I mistakenly pinpointed the fact that the last version of pacman which didn’t showed such issue, was 5.2.2.-4, but by looking at my logs (I also have the habit of keep documents with dates of system updates), seems that the issue is started with pacman 5.2.2.-4; 5.2.2.-3 instead didn’t showed such issue. But certainly the problem relies somewhere else on my system.
By checking the logs, the following issue has started since the following system update:

[Stable Update] 2021-04-18 - Kernels, Mesa, Wine, Plasma5, KDE Frameworks, LibreOffice, Bluez

I already run fsck from live environment and I checked SMART values: the SSD is healtly.

So, in the case that something on my system is causing such issue (eg also by some configuration file), on the live system will be excluded/bypassed?

I actually replied to another user - so did you hijack the other thread?

Yes - generally speaking.

As you specifically mention SSD - is the fstrim.timer enabled?

You can run it manually - but remember the device in question must be mounted for fstrim to work so just open a terminal and issue below command. This will trim all mounted partitions supporting trim with deleted files and provide more info on the process. Wait until the command returns before restarting your system.

sudo fstrim -av

Depending on the result of above - I advise to run a filesystem check on your root partition - before doing anything else.

Running low on disk space on your root partition can also be an issue - and using SSD and not doing regular trim on the device can also result in slow-downs.

If you are using btrfs - then maintenance is surely needed with regular intervals.

Yep, fstrim.timer is enabled and it runs, weekly, fstrim -av from fstrim.service.
The SSD is of 512 GB, and only 12% of space is used; I store big files and other documents on another, external disk. On my laptop I also have a second SSD which I still use for documents and virtual disks for virtualbox.
Filesystem is ext4.

I had no intention to hijack the other thread, since was about pacman 5.2.2-5, the same on which I encountered the problems.
I received a notifications and I thought you replied to me, sorry.
Anyway thank you to have moved my messages to a new discussion.

Can you post some hardware info ?

Full inxi:

System:    Kernel: 4.14.232-1-MANJARO x86_64 bits: 64 compiler: gcc v: 10.2.0 
           parameters: BOOT_IMAGE=/boot/vmlinuz-4.14-x86_64 root=UUID=0d37cf27-2ff0-4234-a80e-4be323299166 rw i915.fastboot=1 
           i915.modeset=1 i915.enable_rc6=0 i915.enable_dc=0 quiet "acpi_osi=Windows 2009" libahci.ignore_sss=1 
           random.trust_cpu=on pcie_aspm=force scsi_mod.use_blk_mq=1 nowatchdog nmi_watchdog=0 mitigations=off 
           nospec_store_bypass_disable noibrs noibpb nopti nospec nospectre_v1 nospectre_v2 l1tf=off mds=off tsx=on 
           tsx_async_abort=off no_stf_barrier kvm-intel.vmentry_l1d_flush=never audit=0 loglevel=0 udev.log_priority=0 
           rd.udev.log_priority=0 rd.systemd.show_status=false net.ifnames=0 systemd.unified_cgroup_hierarchy=true 
           transparent_hugepage=madvise noresume 
           Desktop: Xfce 4.16.0 tk: Gtk 3.24.24 info: xfce4-panel wm: xfwm4 vt: 7 dm: LightDM 1.30.0 Distro: Manjaro Linux 
           base: Arch Linux 
Machine:   Type: Laptop System: Hewlett-Packard product: HP ProBook 6470b v: A1029D1102 serial: <filter> Chassis: type: 10 
           serial: <filter> 
           Mobo: Hewlett-Packard model: 179C v: KBC Version 42.38 serial: <filter> BIOS: Hewlett-Packard v: 68ICE Ver. F.73 
           date: 08/07/2018 
Battery:   ID-1: BAT0 charge: 61.4 Wh (100.0%) condition: 61.4/61.4 Wh (100.0%) volts: 12.3 min: 10.8 
           model: Hewlett-Packard Primary type: Li-ion serial: <filter> status: Full 
           Device-1: hidpp_battery_0 model: Logitech Wireless Touch Keyboard K400 Plus serial: <filter> 
           charge: 100% (should be ignored) rechargeable: yes status: Discharging 
           Device-2: hidpp_battery_1 model: Logitech Wireless Mobile Mouse MX Anywhere 2S serial: <filter> 
           charge: 55% (should be ignored) rechargeable: yes status: Discharging 
Memory:    RAM: total: 15.55 GiB used: 3.54 GiB (22.7%) 
           RAM Report: permissions: Unable to run dmidecode. Root privileges required. 
CPU:       Info: Dual Core model: Intel Core i5-3210M bits: 64 type: MT MCP arch: Ivy Bridge family: 6 model-id: 3A (58) 
           stepping: 9 microcode: 20 cache: L2: 3 MiB bogomips: 19961 
           Speed: 1762 MHz min/max: 1200/3100 MHz Core speeds (MHz): 1: 1762 2: 2246 3: 2066 4: 2968 
           Flags: acpi aes aperfmperf apic arat arch_perfmon avx bts clflush cmov constant_tsc cpuid cpuid_fault cx16 cx8 de 
           ds_cpl dtes64 dtherm dts epb ept erms est f16c flexpriority flush_l1d fpu fsgsbase fxsr ht ibpb ibrs ida lahf_lm lm 
           mca mce mmx monitor msr mtrr nonstop_tsc nopl nx pae pat pbe pcid pclmulqdq pdcm pebs pge pln pni popcnt pse pse36 
           pts rdrand rdtscp rep_good sep smep ss ssbd sse sse2 sse4_1 sse4_2 ssse3 stibp syscall tm tm2 tpr_shadow tsc 
           tsc_deadline_timer vme vmx vnmi vpid x2apic xsave xsaveopt xtopology xtpr 
           Vulnerabilities: Type: itlb_multihit status: KVM: Vulnerable 
           Type: l1tf mitigation: PTE Inversion; VMX: vulnerable 
           Type: mds status: Vulnerable; SMT vulnerable 
           Type: meltdown status: Vulnerable 
           Type: spec_store_bypass status: Vulnerable 
           Type: spectre_v1 status: Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers 
           Type: spectre_v2 status: Vulnerable, IBPB: disabled, STIBP: disabled 
           Type: srbds status: Vulnerable: No microcode 
           Type: tsx_async_abort status: Not affected 
Graphics:  Device-1: Intel 3rd Gen Core processor Graphics vendor: Hewlett-Packard driver: i915 v: kernel bus-ID: 00:02.0 
           chip-ID: 8086:0166 class-ID: 0300 
           Display: x11 server: X.Org 1.20.11 compositor: picom v: git-dac85 driver: loaded: intel unloaded: modesetting 
           alternate: fbdev,vesa display-ID: :0 screens: 1 
           Screen-1: 0 s-res: 1366x768 s-dpi: 207 s-size: 168x94mm (6.6x3.7") s-diag: 193mm (7.6") 
           Monitor-1: LVDS1 res: 1366x768 hz: 60 dpi: 112 size: 310x170mm (12.2x6.7") diag: 354mm (13.9") 
           OpenGL: renderer: Mesa DRI Intel HD Graphics 4000 (IVB GT2) v: 4.2 Mesa 21.0.3 compat-v: 3.0 direct render: Yes 
Audio:     Device-1: Intel 7 Series/C216 Family High Definition Audio vendor: Hewlett-Packard driver: snd_hda_intel v: kernel 
           bus-ID: 00:1b.0 chip-ID: 8086:1e20 class-ID: 0403 
           Sound Server-1: ALSA v: k4.14.232-1-MANJARO running: yes 
           Sound Server-2: JACK v: 0.125.0 running: no 
           Sound Server-3: PulseAudio v: 14.2 running: yes 
Network:   Device-1: TP-Link Archer T9UH v1 [Realtek RTL8814AU] type: USB driver: 8814au bus-ID: 4-3:126 chip-ID: 2357:0106 
           class-ID: 0000 serial: <filter> 
           IF: wlan0 state: up mac: <filter> 
           IP v4: <filter> type: dynamic noprefixroute scope: global broadcast: <filter> 
           WAN IP: <filter> 
Bluetooth: Message: No bluetooth data found. 
Logical:   Message: No logical block device data found. 
RAID:      Message: No RAID data found. 
Drives:    Local Storage: total: 698.65 GiB used: 74.9 GiB (10.7%) 
           SMART Message: Unable to run smartctl. Root privileges required. 
           ID-1: /dev/sda maj-min: 8:0 vendor: Samsung model: SSD 860 EVO 500GB size: 465.76 GiB block-size: physical: 512 B 
           logical: 512 B speed: 6.0 Gb/s rotation: SSD serial: <filter> rev: 4B6Q scheme: MBR 
           ID-2: /dev/sdb maj-min: 8:16 vendor: Crucial model: CT250MX500SSD1 size: 232.89 GiB block-size: physical: 4096 B 
           logical: 512 B speed: 6.0 Gb/s rotation: SSD serial: <filter> rev: 023 scheme: MBR 
           Message: No optical or floppy data found. 
Partition: ID-1: / raw-size: 465.76 GiB size: 457.45 GiB (98.22%) used: 32.58 GiB (7.1%) fs: ext4 dev: /dev/sda1 maj-min: 8:1 
           label: N/A uuid: 0d37cf27-2ff0-4234-a80e-4be323299166 
           ID-2: /home/<filter>/mounts/servicedisk raw-size: 232.88 GiB size: 228.23 GiB (98.00%) used: 42.32 GiB (18.5%) 
           fs: ext4 dev: /dev/sdb1 maj-min: 8:17 label: servicedisk uuid: 8412b438-5d7b-48bd-bfb1-46666bb7ac64 
Swap:      Alert: No swap data was found. 
Unmounted: Message: No unmounted partitions found. 
USB:       Hub-1: 1-0:1 info: Full speed (or root) Hub ports: 2 rev: 2.0 speed: 480 Mb/s chip-ID: 1d6b:0002 class-ID: 0900 
           Hub-2: 1-1:2 info: Intel Integrated Rate Matching Hub ports: 6 rev: 2.0 speed: 480 Mb/s chip-ID: 8087:0024 
           class-ID: 0900 
           Hub-3: 1-1.2:3 info: VIA Labs VL813 Hub ports: 4 rev: 2.1 speed: 480 Mb/s chip-ID: 2109:2813 class-ID: 0900 
           Device-1: 1-1.2.1:4 info: Logitech Unifying Receiver type: Keyboard,Mouse,HID driver: logitech-djreceiver,usbhid 
           interfaces: 3 rev: 2.0 speed: 12 Mb/s power: 98mA chip-ID: 046d:c52b class-ID: 0300 
           Device-2: 1-1.2.2:10 info: Logitech F310 Gamepad [DirectInput Mode] type: HID driver: logitech,usbhid interfaces: 1 
           rev: 2.0 speed: 12 Mb/s power: 100mA chip-ID: 046d:c216 class-ID: 0300 serial: <filter> 
           Hub-4: 2-0:1 info: Full speed (or root) Hub ports: 2 rev: 2.0 speed: 480 Mb/s chip-ID: 1d6b:0002 class-ID: 0900 
           Hub-5: 2-1:2 info: Intel Integrated Rate Matching Hub ports: 6 rev: 2.0 speed: 480 Mb/s chip-ID: 8087:0024 
           class-ID: 0900 
           Device-1: 2-1.6:3 info: Broadcom HP Portable SoftSailing type: <vendor specific> driver: N/A interfaces: 4 rev: 2.0 
           speed: 12 Mb/s chip-ID: 0a5c:21e1 class-ID: fe01 serial: <filter> 
           Hub-6: 3-0:1 info: Full speed (or root) Hub ports: 4 rev: 2.0 speed: 480 Mb/s chip-ID: 1d6b:0002 class-ID: 0900 
           Hub-7: 4-0:1 info: Full speed (or root) Hub ports: 4 rev: 3.0 speed: 5 Gb/s chip-ID: 1d6b:0003 class-ID: 0900 
           Device-1: 4-3:126 info: TP-Link Archer T9UH v1 [Realtek RTL8814AU] type: Network driver: 8814au interfaces: 1 
           rev: 3.0 speed: 5 Gb/s power: 864mA chip-ID: 2357:0106 class-ID: 0000 serial: <filter> 
Sensors:   System Temperatures: cpu: 41.0 C mobo: 0.0 C 
           Fan Speeds (RPM): N/A 
Info:      Processes: 172 Uptime: 2d 10h 31m wakeups: 850 Init: systemd v: 247 tool: systemctl Compilers: gcc: 10.2.0 
           Packages: pacman: 1671 lib: 433 Shell: Bash v: 5.1.4 running-in: xfce4-terminal inxi: 3.3.04
  1. You hsould update the kernel to version 4.19 or higher: 5.4 or better 5.10.
  2. You have a dual core CPU only. This might be cause of the slow down.

During these years and also periodically I tried newer kernels, but on my laptop the 4.14 defenitely gave the best performances; also I don’t have/use new hardware.

Yep, but it also has hyper threading, and as I’ve said, such issue in particular, in past, never occurred: if would be due a dual core only CPU, wouldn’t be this issue occurred since the first day and first time?
The system, despite the old CPU (Intel Core i5-3210M), is always snappy and fast, also the compilation of packages is good and the temperatures are always ok, and I never see slowdowns elsewhere.

An example: if I run stress --cpu $(nproc --all) I am still able to do normal operations, like browsing and listening music, without hiccups.

Maybe the slowdown on installing the updates is caused by cache writing on the disc.

I quickly tested the disk (SSD) read/write:


dd if=/dev/zero of=tempfile bs=1M count=4096 conv=fdatasync,notrunc status=progress
4294967296 bytes (4,3 GB, 4,0 GiB) copied, 8 s, 536 MB/s
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB, 4,0 GiB) copied, 8,09634 s, 530 MB/s


dd if=tempfile of=/dev/null bs=1M count=4096 status=progress
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB, 4,0 GiB) copied, 0,513774 s, 8,4 GB/s

sudo hdparm -Tt /dev/sda
[sudo] password for dave: 

 Timing cached reads:   14054 MB in  2.00 seconds = 7031.28 MB/sec
 Timing buffered disk reads: 1622 MB in  3.00 seconds = 540.00 MB/sec

Especially by looking at the writing test with dd seems that the disk (SSD) have good performance.
What else can/should I check?

However: I am on the Stable branch: at the next Stable Update I will try to performs the update from live USB by using chroot, to see if something is wrong at software level; in anyway I’ll report here the result.


For completeness, here the info taken from hdparm:

	Enabled	Supported:
	   *	SMART feature set
	   *	Security Mode feature set
	   *	Power Management feature set
	   *	Write cache
	   *	Look-ahead
	   *	Host Protected Area feature set
	   *	WRITE_BUFFER command
	   *	READ_BUFFER command
	   *	NOP cmd
	    	SET_MAX security extension
	   *	48-bit Address feature set
	   *	Device Configuration Overlay feature set
	   *	Mandatory FLUSH_CACHE
	   *	SMART error logging
	   *	SMART self-test
	   *	General Purpose Logging feature set
	   *	64-bit World wide name
	    	Write-Read-Verify feature set
	   *	{READ,WRITE}_DMA_EXT_GPL commands
	   *	Gen1 signaling speed (1.5Gb/s)
	   *	Gen2 signaling speed (3.0Gb/s)
	   *	Gen3 signaling speed (6.0Gb/s)
	   *	Native Command Queueing (NCQ)
	   *	Phy event counters
	   *	READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
	   *	DMA Setup Auto-Activate optimization
	    	Device-initiated interface power management
	   *	Asynchronous notification (eg. media change)
	   *	Software settings preservation
	    	Device Sleep (DEVSLP)
	   *	SMART Command Transport (SCT) feature set
	   *	SCT Write Same (AC2)
	   *	SCT Error Recovery Control (AC3)
	   *	SCT Features Control (AC4)
	   *	SCT Data Tables (AC5)
	   *	Device encrypts all user data
	   *	WRITE BUFFER DMA command
	   *	READ BUFFER DMA command
	   *	Data Set Management TRIM supported (limit 8 blocks)
	   *	Deterministic read ZEROs after TRIM

In particular, Write cache, is enabled.

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 :slight_smile:

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:

  1. manjaro-chroot -a
  2. sudo pacman-mirrors -c all
  3. sudo 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 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:

[Stable Update] 2021-05-19 - Kernels, Nvidia, KDE Frameworks, Plasma, Systemd, LibreOffice, KDE Gear Mobile, FF, TB

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.