I have been using Fedora 38 for a couple of months now, and I’ve noticed that it seems very slow to boot, and reach a state where it is usable. That is, I’m logged in and the system is usable (I’m not waiting three minutes for an ap to start).
I’ve looked at ksysguard, and in the Process Table tab cpu usage seems to be negligible. Often ksysguard itself is using the most cpu. But when I switch over to System Load I see that all four cpus are running at 100% a lot of the time. Total cpu ranges from about 25% to 40%. Memory usage is small, about 3Gb out of 16Gb installed. Swap is unused.
Then, after about half an hour, it all goes away. cpu usage drops to a few percent for all of them and the system runs as it should.
So my question is, what is soaking up all my cpu? Why doesn’t it show up in the Process Table? Is there anything I can do to improve performance, or do I just get used to half hour boot time?
I usually just sleep the system, which is fine, but I occasionally use other OSes on my PC, so have to reboot back into Fedora.
All advice gratefully received.
By mentioning Ksysguard, I’m guessing you are usimg the KDE spin correct?
So you can start by checking system processes. Many system monitoring apps only show processes you created initially and hide those created by the system. I’m unfamiliar with Ksysguard so I don’t know how to view system processes.
As for the slow boot time try running the following command, it will give you an idea of what is taking so long.
systemd-analyze blame
Just by the information you provided alone, I’m unsure as to what the problem is, but seeing system processes and the output of the above command might help in figuring out what is happening.
Maybe its baloo (kde indexing service)?
Try using top on a terminal.
In its header it breaks down cpu time into its different types.
What is the sys, user, io and idle you see?
If the io cpu high could be that slow disks or high io activity.
Thanks for the replies, much appreciated.
I tried the “top” command but it basically told me the same thing as the System Load tab in ksysguard, that ksysguard was the ap using the most cpu, 2-3%. But I think I was too late, the system had already settled down.
systemd-analyze blame was interesting. It took me a little while to figure out what it all meant, and I’m still not totally clear, but I think it’s listing how long each of the initialisation processes took, longest first. The highest one was NetworkManager-wait-online.service at 53 seconds. I guess that’s how long it took to connect to the net?
The rest of them appear to be connecting to disks. I probably should have mentioned I’ve got three disks on my system; an internal 500Gb, a 3Tb USB drive and a 5Tb USB drive. The 3Tb has 11 partitions, and four OSes installed on it, including Fedora. The 5Tb has seven partitions, but no OSes installed on it. The internal drive has my daily driver, Mint. I should probably also mention that my PC is very old, so probably has very slow USB speed.
So it seems it’s taking a long time to access all the partitions and work out what they are. Or something. Not sure what the OS needs to do, but it seems to take a while. It must do a lot of this stuff in parallel though, otherwise it would take days to boot. They take about 30 seconds each, and there seems to be a lot of them, ten or so lines of output for each partition.
I output the results to a file to upload, but I can’t figure out how to upload a file.
Anyway I think I can safely call this one solved.
Thanks again to all who replied, especially @mr-scientific who pointed me in the right direction.
If booting from fedora with an older machine that may only have USB 2.0 and using a disk attached via usb then it certainly can take some time to boot and to perform many other tasks. What time did the ‘systemd-analyze blame’ show as the final time - that would be the last time noted and would be the time the system came available to log in (the first line displayed)
Thanks @computersavvy, I’m not sure I understand your question. The first line was 53 seconds as in the screenshot.
The last line in the file only took 2ms, in fact the last few tasks only took milliseconds.
I’ve uploaded the whole file to Dropbox, here’s the link. Dropbox - blame.txt - Simplify your life
The problem however is not logging in, well it sort of is but I can login, it just takes a long time. Then trying to do anything also takes a lot longer than I’d like. Opening Dolphin, for instance, takes almost a minute. Opening Vivaldi and Thunderbird take a lot longer, but they have a lot more to do I guess. I booted Fedora over ten minutes ago now, and cpu is still at about 30%.
Well, it’s now been about twenty minutes and the cpu has dropped to something like normal, between one and five percent.
In the last ten minutes, as I was trying to upload the file to Dropbox, the system froze twice. The first time for maybe ten second, the second time for closer to a minute. Ksysguard froze completely, and so did the cursor. Absolutely nothing worked. Then it all came good again.
Could some system updates be happening in the background or something?
I have actually ordered a new computer from Ebay, with 16Gb ram and a 256Gb SSD which will probably get Fedora installed on it. Maybe that will solve the problems, at least partially. I got this PC for nothing ten years ago, so maybe it’s getting a bit tired.
:-\
systemd-analyze blame reports the total time from the start of the boot process for each line item to complete. The line items are not serially performed, with each adding to the total before, but are shown as the cumulative time required to reach and complete that item.
You may use man systemd-analyze to find out many different ways that command may be used. The sub-commands ‘blame’, ‘critical-chain’, and ‘plot’ are ones that i find very useful. I have not ever used all the available sub-commands as there are many.
Amount of memory, speed of processor, # of cpu cores, size of drive, and many other factors can contribute to performance on PCs. The command inxi -Fzxx can show much about the system that might be relevant.
Agreed suggest @mogplus8 starts with systemd-analyze critical-chain as its a modest amount of output. And can be posted here.
Theres something strange with your disks.
The initialisation time is 38 secs.
For my two very old (12 years old) SATA disks initialisation time is 2 sec by systemd-analyze blame command
Thanks for the responses.
I tried systemd-analyze critical-chain, the output is below.
I should probably mention that Fedora is doing some major updates as I’m doing this, and maybe that’s affecting things. What I have observed over the last fifteen minutes or so is that, on several occasions, all four cpus have been at 100% for perhaps 20 to 30 seconds. But as occurred last time, the Process Table tab of ksysguard showed that the most cpu was being used by ksysguard itself, and usually around 3%.
ian@Fedorian ~]$ systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
└─sysinit.target @34.903s
└─systemd-update-utmp.service @34.861s +42ms
└─auditd.service @33.625s +1.224s
└─systemd-tmpfiles-setup.service @32.612s +980ms
└─systemd-journal-flush.service @12.177s +20.421s
└─systemd-journald.service @11.685s +489ms
└─systemd-journald-audit.socket @11.667s
└─system.slice
└─-.slice
Here’s the output of the inxi command.
[ian@Fedorian ~]$ inxi -Fzxx
System:
Kernel: 6.4.6-200.fc38.x86_64 arch: x86_64 bits: 64 compiler: gcc
v: 2.39-9.fc38 Desktop: KDE Plasma v: 5.27.6 tk: Qt v: 5.15.10
wm: kwin_wayland dm: SDDM Distro: Fedora release 38 (Thirty Eight)
Machine:
Type: Desktop System: Hewlett-Packard product: HP Compaq Pro 4300 SFF PC
v: N/A serial: <superuser required> Chassis: type: 3
serial: <superuser required>
Mobo: Hewlett-Packard model: 2ADE v: 1.0 serial: <superuser required>
UEFI: AMI v: 8.12 date: 09/04/2013
CPU:
Info: quad core model: Intel Core i5-3470S bits: 64 type: MCP
arch: Ivy Bridge rev: 9 cache: L1: 256 KiB L2: 1024 KiB L3: 6 MiB
Speed (MHz): avg: 1598 high: 1600 min/max: 1600/3600 cores: 1: 1600
2: 1596 3: 1597 4: 1600 bogomips: 23146
Flags: avx ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
Device-1: Intel Xeon E3-1200 v2/3rd Gen Core processor Graphics
vendor: Hewlett-Packard driver: i915 v: kernel arch: Gen-7 ports:
active: HDMI-A-1,VGA-1 empty: DP-1 bus-ID: 00:02.0 chip-ID: 8086:0152
Display: wayland server: X.org v: 1.20.14 with: Xwayland v: 22.1.9
compositor: kwin_wayland driver: N/A d-rect: 3360x2100 display-ID: 0
Monitor-1: HDMI-A-1 pos: primary,top-left res: 1920x1200 size: N/A
Monitor-2: VGA-1 pos: bottom-r res: 1440x900 size: N/A
API: OpenGL v: 4.2 Mesa 23.1.4 renderer: Mesa Intel HD Graphics 2500 (IVB
GT1) direct-render: Yes
Audio:
Device-1: Intel 6 Series/C200 Series Family High Definition Audio
vendor: Hewlett-Packard driver: snd_hda_intel v: kernel bus-ID: 00:1b.0
chip-ID: 8086:1c20
Device-2: Focusrite-Novation Speedio
driver: hid-generic,snd-usb-audio,usbhid type: USB rev: 1.1 speed: 12 Mb/s
lanes: 1 bus-ID: 2-1.5:4 chip-ID: 1235:0002
API: ALSA v: k6.4.6-200.fc38.x86_64 status: kernel-api
Server-1: PipeWire v: 0.3.75 status: active with: 1: pipewire-pulse
status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
4: pw-jack type: plugin
Network:
Device-1: Qualcomm Atheros AR9227 Wireless Network Adapter driver: ath9k
v: kernel bus-ID: 04:01.0 chip-ID: 168c:002d
IF: wlp4s1 state: down mac: <filter>
Device-2: Broadcom NetLink BCM57788 Gigabit Ethernet PCIe
vendor: Hewlett-Packard driver: tg3 v: kernel pcie: speed: 2.5 GT/s lanes: 1
port: N/A bus-ID: 05:00.0 chip-ID: 14e4:1691
IF: enp5s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Drives:
Local Storage: total: 7.73 TiB used: 273.57 GiB (3.5%)
ID-1: /dev/sda vendor: Western Digital model: WD5000AAKX-60U6AA0
size: 465.76 GiB speed: 3.0 Gb/s serial: <filter>
ID-2: /dev/sdb vendor: Western Digital model: WD30NMZW-11GX6S1
size: 2.73 TiB type: USB rev: 2.1 spd: 480 Mb/s lanes: 1 serial: <filter>
ID-3: /dev/sdc vendor: Western Digital model: WD50NDZW-11BCSS0
size: 4.55 TiB type: USB rev: 2.1 spd: 480 Mb/s lanes: 1 serial: <filter>
Partition:
ID-1: / size: 464.73 GiB used: 71.97 GiB (15.5%) fs: btrfs dev: /dev/sdb11
ID-2: /boot size: 942.3 MiB used: 295.9 MiB (31.4%) fs: ext4
dev: /dev/sdb10
ID-3: /boot/efi size: 974.1 MiB used: 17.4 MiB (1.8%) fs: vfat
dev: /dev/sdb5
ID-4: /home size: 464.73 GiB used: 71.97 GiB (15.5%) fs: btrfs
dev: /dev/sdb11
Swap:
ID-1: swap-1 type: zram size: 8 GiB used: 768 KiB (0.0%) priority: 100
dev: /dev/zram0
ID-2: swap-2 type: partition size: 7.81 GiB used: 0 KiB (0.0%)
priority: -2 dev: /dev/sdb8
Sensors:
System Temperatures: cpu: 27.0 C mobo: N/A
Fan Speeds (RPM): N/A
Info:
Processes: 342 Uptime: 2h 32m Memory: available: 15.5 GiB
used: 6.2 GiB (40.0%) Init: systemd v: 253 target: graphical (5)
default: graphical Compilers: gcc: 13.1.1 Packages: pm: rpm pkgs: N/A
note: see --rpm pm: flatpak pkgs: 26 Shell: Bash v: 5.2.15
running-in: konsole inxi: 3.3.27
Thanks again for the help.
Ian
I see 2 things of concern (but they may be related)
- During boot we see
└─systemd-journal-flush.service @12.177s +20.421s
└─systemd-journald.service @11.685s +489ms
└─systemd-journald-audit.socket @11.667s
which indicates that even after the journald flush service starts it takes over 20 seconds to complete.
- From inxi we see that you are booting from sdb, which is attached at a USB 2 port and data transfer is limited to 480 Mb/s, (mega bits per second) which drastically limits the data transfer rate and extends boot time. You also appear to have swap configured on the same drive and that has the same limitations. USB 2 provides the slowest possible data transfer rates for modern computers.
Thanks @computersavvy, I guess that confirms my original suspicion, running Fedora from a USB drive is definitely not recommended! I didn’t know about the swap issue though, although it appears (from ksysguard) that swap is not used. It’s still sitting at zero.
I read in another post on this issue that it appeared that kernel version 6.4 may have been causing the problem. I tried booting into an earlier kernel (6.3.12) and I have to say it does seem to be performing better. cpu use is still very high during boot, but it settled down quite quickly and is now running at about 2%. Here is the systemd-analyze critical-chain from just now.
graphical.target @1min 39.460s
└─multi-user.target @1min 39.460s
└─virtqemud.service @1min 33.011s +6.447s
└─remote-fs.target @1min 32.999s
└─remote-fs-pre.target @1min 32.999s
└─nfs-client.target @1min 24.741s
└─gssproxy.service @1min 21.300s +3.440s
└─network.target @1min 21.284s
└─wpa_supplicant.service @1min 23.374s +2.425s
└─dbus-broker.service @34.283s +6.783s
└─dbus.socket @33.895s
└─sysinit.target @33.870s
└─systemd-resolved.service @32.573s +1.296s
└─systemd-tmpfiles-setup.service @31.441s +1.055s
└─systemd-journal-flush.service @12.281s +19.144s
└─systemd-journald.service @11.730s +536ms
└─systemd-journald-audit.socket @11.709s
└─system.slice
└─-.slice
To my untrained eye the times don’t seem to have changed much…
:-\
Timing on boot does not seem to have changed much. The slow parts still seem the ones I noted above, as that delays the next step by ~31 seconds of the total 39 second boot. I believe the delay in journald may be due to the slow device access.
As far as the swap is concerned, fedora does not create a physical swap by default. It uses the zram for that purpose and in most situations additional swap is not required.
@computersavvy you conclusion makes sense. When I get my new computer hopefully most of the problem will go away.
I actually received the PC I ordered from Ebay, but it was advertised as new and a second hand one turned up. I’m in the process of getting my money back. The seller is not cooperating, yet…
What is going to be slow is using usb-2.
If you have usb-3 then its very fast and very usable.
I have a usb-3 ssd that i have installed fedora on as a rescue drive.
I also use it to test for possible hardware issues with new fedora releases.
Faster – I agree
But still not nearly comparable to an internal drive (even an HDD) for data transfer speeds. This from wikipedia about the USB standards.
SATA 3 is rated 6 Gb/s which is still about 5 times faster than the fastest USB 3.2 rating for any single channel. An M.2 (PCIe) interface is much faster than even that.
Had an epiphany this morning. Are we barking up the wrong tree? It seems to me that slow data transfer speeds (while slowing response) are not going to cause excessive cpu usage, in fact the opposite should be the case. The cpus should be quiescent, waiting for data to arrive for it to process. So whatever is causing the high cpu usage must be something that is running in memory, and doing an awful lot of work to hammer the cpus the way it is. What it probably isn’t doing is accessing the disks, not even the internal 500G drive, or any other peripherals for that matter. So what is it doing, calculating the meaning of life, the universe and everything?..
As I mentioned, I read in another post that the latest kernel (6.4.something) seems to have some performance issues. I’m using an earlier kernel and it does feel a bit better. It still thrashes the cpus on startup, but not for quite as long it seems. Although I don’t have any quantitative data so support that assertion…
:-\
Not necessarily correct.
For example the tracker-miner service hammers devices as it builds the db and requires a lot of other cpu activity to organize that data – not just IO involved. Any graphics that is not using hardware acceleration hammers the cpu with rendering. Other sources of cpu intensive activity exist as well.
The top command may give some info about cpu usage
The command iostat from the sysstat package can show you how much disk IO you have. Another indication is the “S” column in the top display. That is the process status and “D” means waiting for disk IO.