1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About Ubuntu
Ubuntu 18.04.1 LTS
2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center
linux-image-generic 4.15.0.43.45
3) What you expected to happen
HDD performance is not unnecessary slow by default because the wrong "cfq" IO scheduler is used
4) What happened instead
HDD performance is slow compared to other systems where other IO scheduler like "deadline" or "noop" is used. Even random OOM killings occur because swap performance is too low.
Hi all,
About a year ago I moved from CentOS 7 to Ubuntu 18.04 on a couple of older desktop and laptop machines. One of the things I noticed after the switch, was that disk IO performances seemed to be degraded, and the machines often became unresponsive with lot of IO load, like copying files or swapping when a lot of memory was used. People on other Ubuntu machines with HDD that I know or use the mentioned machines, also complained about annoying system lockups and hangs. Degrading IO performance could be caused by many things, like drivers, wrong block size aligning, heavier desktop environment and applications and browsers and web applications that become heavier in RAM and IO usage. I tried several things like using lighter XFCE environment, switching from Firefox to Chrome, adding adblockers and webtracker blockers, and using a tab suspension plugin, to lower memory usage. But low performance issues still remained and it appeared that especially swapping became terribly slow and even the kernel OOM killer started killing random applications, something I haven't experienced before on desktop machines.
After a while I found out that on the old CentOS 7 installs, the disk IO scheduler was set to "deadline", while on the Ubuntu 18.04 installs, it is "cfq". So a month ago on three Ubuntu 18.04 I switched the scheduler from "cfq" to "noop". Guess what, after a month I can conclude that the machines turned to be much more responsive, no strange OOM killings anymore, and even when significant swap is used, the machine is still responsive and workable. I set it on other peoples computers as well and also there, complaints about slowness disappeared.
Could it be that
1. the CFQ schedulers, that stands for "Complete Fairness Queueing", is causing all processes to use disk IO randomly simultaneously, and that is causing heavy seeking activity on old-fashion rotating HDDs, causing it to severely lower the IO throughput?
2. it is better to by default use the "deadline" or "noop" IO scheduler for HDDs, by putting the following in /etc/udev/rules.d/50-scheduler.rules:
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1",ATTR{queue/scheduler}="noop"
to gain much better IO performance in general for "older" systems using HDDs.
3. is this something others experience as well, although I think there is no 'placebo' effect on my side. Is it wise to test with some benchmark?
Systems involved that I tested:
1. AMD Athlon(tm) II X4 640 Processor, 8GB RAM, Western Digital Blue 7200rpm 1TB disk (WDC WD10EZEX-00BN5A0)
2. Acer Aspire R3-471T-33NP laptop, Intel(R) Core(TM) i3-4005U CPU, 4GB RAM, Seagate Laptop Thin HDD 5400rpm 500GB disk (ST500LT012-1DG142)
3. Acer Veriton L4630G desktop, Intel(R) Core(TM) i5-4440S CPU, 8GB RAM, Western Digital Red 5400rpm 3TB disk (WDC WD30EFRX-68EUZN0)
These machines are all installed with LVM and amount of swap that equals the amount of RAM, contrary the Ubuntu defaults of configuring plain disk partitions and only 950MB of swap. This mainly because I want the flexibility of LVM when I need to change disk configurations later on, and I want to be able to use Hibernation (suspend to disk)
Typical usage: browsing websites, emailing using Thunderbird, using LibreOffice documents, occasional copying over large amounts of files to/from external USB disks, occasional image and video editing.
I see my more modern Thinkpad T450s laptop with SSD with Ubuntu 18.04 is also using CFQ, but there I never experience IO slowness, even when GBs of swap are in use. Probably CFQ works fine with SSDs that have much lower seek times.
---
ProblemType: Bug
ApportVersion: 2.20.9-0ubuntu7.5
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC1: bastiaan 1878 F.... pulseaudio
/dev/snd/controlC0: bastiaan 1878 F.... pulseaudio
CurrentDesktop: KDE
DistroRelease: Ubuntu 18.04
HibernationDevice: RESUME=/dev/kubuntu-vg/swap_1
InstallationDate: Installed on 2018-09-05 (137 days ago)
InstallationMedia: Kubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
IwConfig:
lo no wireless extensions.
enp6s0 no wireless extensions.
MachineType: MSI MS-7599
NonfreeKernelModules: nvidia_modeset nvidia
Package: linux (not installed)
ProcFB: 0 VESA VGA
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-43-generic root=/dev/mapper/kubuntu--vg-root ro quiet acpi=off noacpi
ProcVersionSignature: Ubuntu 4.15.0-43.46-generic 4.15.18
RelatedPackageVersions:
linux-restricted-modules-4.15.0-43-generic N/A
linux-backports-modules-4.15.0-43-generic N/A
linux-firmware 1.173.3
RfKill:
Tags: bionic
Uname: Linux 4.15.0-43-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare scanner sudo
_MarkForUpload: True
dmi.bios.date: 09/09/2010
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: V17.7
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: 870A-G54 (MS-7599)
dmi.board.vendor: MSI
dmi.board.version: 3.0
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: MSI
dmi.chassis.version: 3.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrV17.7:bd09/09/2010:svnMSI:pnMS-7599:pvr3.0:rvnMSI:rn870A-G54(MS-7599):rvr3.0:cvnMSI:ct3:cvr3.0:
dmi.product.family: To Be Filled By O.E.M.
dmi.product.name: MS-7599
dmi.product.version: 3.0
dmi.sys.vendor: MSI
This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:
apport-collect 1812569
and then change the status of the bug to 'Confirmed'.
If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.
This change has been made by an automated script, maintained by the Ubuntu Kernel Team.