Re: [Dorset] Slow computer
On 22/08/2020 12:13, Ralph Corderoy wrote: Hi Peter, Processor : Intel(R) Pentium(R) CPU G3420 @ 3.20GHz Memory: 8037MB (4978MB used) As you say, only two, non-HyperThreaded, cores, but plenty of RAM space. Are your main filesystems on a rusty hard drive rather than an SSD? I'm guessing there are multiple concurrent programs fighting over the I/O they require and causing the hard drive to spend its time seeking back and forth, with a little reading and writing in between. Thanks Ralph, Yes, I am working on Spinning rust, and I had a panic yesterday when it wouldn't even boot, But I swapped out the hard disk for another to prove that the system was still OK, then replugged the memory and HD connections and it all seems OK, even a bit faster. I also using Discover removed a couple of programs such as Bluetooth and Braille and stopped pppd-dns.service and something else modem related. I will implement your suggestions as well. Much appreciated. On another topic, SWMBO has been complaining about poor Wifi where she rests in the kitchen, so today I bought a TP-Link range extender, and she is happy with the result. BUT that thing was a B*r to set up and kept disconnecting and didn't follow the instructions that came with it or were available on-line. It's an RE305 and I wouldn't recommend them for that reason. Cheers, Peter -- Next meeting: Online, Jitsi, Tuesday, 2020-09-01 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Slow computer
Hi Peter, > > > Processor : Intel(R) Pentium(R) CPU G3420 @ 3.20GHz > > > Memory: 8037MB (4978MB used) As you say, only two, non-HyperThreaded, cores, but plenty of RAM spare. > > > $ systemd-analyze blame > > > 3min 12.427s apt-daily.service > > > 43.818s man-db.service > > > 29.566s udisks2.service > > > 28.056s mpd.service > > > 23.120s networkd-dispatcher.service > > > 20.561s fwupd-refresh.service > > > 17.882s snapd.service Are your main filesystems on a rusty hard drive rather than an SSD? I'm guessing there are multiple concurrent programs fighting over the I/O they require and causing the hard drive to spend its time seeking back and forth, with a little reading and writing in between. > $ 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. > > graphical.target @54.613s > └─multi-user.target @54.613s > └─mpd.service @32.239s +22.372s That says mpd.service, the Music Player Daemon, took 22 seconds to run. Perhaps the mpd server is indexing your music collection on start-up. Rather than have mpd start at boot, you can have it start when first needed. This is detected by a client program attempting to contact it on its socket. https://wiki.archlinux.org/index.php/Music_Player_Daemon#Socket_activation To configure it in that way, run sudo -i systemctl disable --now mpd.service sudo -i systemctl enable --now mpd.socket mpd.service should no longer appear in ‘systemd-analyze blame’ output after the next boot. ‘blame’ above also has > > > 43.818s man-db.service That's indexing the man pages on your system. Again, something that generally need not happen on boot. It's scheduled by man-db.timer; see ‘systemctl cat man-db.timer’. ‘systemctl list-timers’ in a wide terminal should show man-db.timer, when it last ran, and when it's next scheduled. I've altered that here to run at a set time when I know the PC is likely to be on and fairly idle. ‘sudo -i systemctl edit man-db.timer’ puts me in an editor with an empty file where I add the lines [Timer] OnCalender= OnCalendar=20:02 Persistent=no Alter ‘20:02’ to suit. The ‘Persistent=no’ stops systemd running the timer at boot when it spots it missed a scheduled run during down-time. Instead, it will wait for the next scheduled time. Repeating the ‘systemctl cat man-db.timer’ above should show an ‘override.conf’ with your new lines, and ‘systemctl list-timers’ a new ‘next run’ time. -- Cheers, Ralph. -- Next meeting: Online, Jitsi, Tuesday, 2020-09-01 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Slow computer
On 20/08/2020 09:36, Ralph Corderoy wrote: Hi Peter, $ systemd-analyze blame Please provide the output of systemd-analyze time systemd-analyze critical-chain peterm@peterm-MBB-34204H:~$ systemd-analyze time Startup finished in 3.412s (kernel) + 54.628s (userspace) = 58.041s graphical.target reached after 54.613s in userspace peterm@peterm-MBB-34204H:~$ 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. graphical.target @54.613s └─multi-user.target @54.613s └─mpd.service @32.239s +22.372s └─network.target @32.109s └─NetworkManager.service @21.848s +10.260s └─dbus.service @21.845s └─basic.target @21.751s └─sockets.target @21.751s └─snapd.socket @21.750s +1ms └─sysinit.target @21.523s └─cryptsetup.target @21.516s └─systemd-ask-password-wall.path @3.329s └─-.mount @3.314s └─system.slice @3.314s └─-.slice @3.314s peterm@peterm-MBB-34204H:~$ -- Next meeting: Online, Jitsi, Tuesday, 2020-09-01 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Slow computer
Hi Peter, > $ systemd-analyze blame Please provide the output of systemd-analyze time systemd-analyze critical-chain -- Cheers, Ralph. -- Next meeting: Online, Jitsi, Tuesday, 2020-09-01 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
[Dorset] Slow computer
I notice that my computer takes nearly two minutes to boot in the morning and the first load of any program also takes a long time. I am running Kubuntu 20.04 on a dual core homebuilt computer. Hardinfo gives: Processor : Intel(R) Pentium(R) CPU G3420 @ 3.20GHz Memory : 8037MB (4978MB used) Machine Type : Desktop Operating System : Ubuntu 18.04.2 LTS User Name : peterm (Peter Merchant) Date/Time : Wed 25 Mar 2020 10:02:24 GMT -Display- Resolution : 1680x1050 pixels I came across an article in Feb 2019 Linux Format about bootchart and the discussion there is about using systemd-analyze blame which shows how many units are running and how long they take to start. BUT, which ones can I remove? Being just a user and not a guru, I don't know what many of these do or if they can be removed safely. Thanks for any advice. Peter. Here is a few - not all: peterm@peterm-MBB-34204H:~$ systemd-analyze blame 3min 12.427s apt-daily.service 43.818s man-db.service 29.566s udisks2.service 28.056s mpd.service 23.120s networkd-dispatcher.service 20.561s fwupd-refresh.service 17.882s snapd.service 15.714s accounts-daemon.service 15.139s NetworkManager-wait-online.service 15.120s systemd-journal-flush.service 14.216s dev-sda1.device 13.608s plymouth-start.service 12.222s ModemManager.service 11.719s polkit.service 11.453s NetworkManager.service 11.434s avahi-daemon.service 10.846s thermald.service 10.845s wpa_supplicant.service 10.763s systemd-logind.service 6.828s logrotate.service 5.145s colord.service 5.048s gpu-manager.service 3.902s rsyslog.service 2.730s apport.service 2.639s grub-common.service 2.510s systemd-udevd.service 2.402s grub-initrd-fallback.service 2.209s e2scrub_reap.service 2.105s apt-daily-upgrade.service 2.078s user@1000.service 2.049s upower.service 1.967s lm-sensors.service 1.782s systemd-fsck@dev-disk-by\x2duuid-9f18c277\x2d0c1d\x2d4314\x2daf14\x2d5343168f4360.service 1.608s apparmor.service 1.117s clamav-daemon.service 1.070s snapd.seeded.service 1.004s plymouth-read-write.service 880ms systemd-resolved.service -- Next meeting: Online, Jitsi, Tuesday, 2020-09-01 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
