Slow disk writes after some uptime, only on 32bit/16+RAM/4+ kernels
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Debian) |
Unknown
|
Unknown
|
|||
linux-hwe (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
This happens on xenial with 4.4 and 4.8 kernels.
It does not happen on precise with 3.2, nor on trusty with 3.19.
The problem is that disk writes start with 200 MB/sec, but after some disk usage, e.g. after 20-50 GB of writes, they become extremely slow, like 2 MB/sec, and never get fast again.
The difference is really 100 times slower, it's not related to RAM caching, it makes the system unusable permanately after it appears.
Test case [edit: see comment #7 below for my updated test case]:
# This copies with 200 MB/sec:
dd if=/dev/zero of=/mnt/test bs=1M count=1000 conv=fdatasync
# This just does some disk writes, because the problem happens gradually
cp -a /mnt/a-20gb-folder /mnt/dest
# Now testing again, it writes with 2 MB/sec:
dd if=/dev/zero of=/mnt/test bs=1M count=1000 conv=fdatasync
After those 3 commands, the system is unusable even if left for hours.
I've only seen it in 2 out of 100 installations so far, so it appears to be rare...
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: linux-image-
ProcVersionSign
Uname: Linux 4.8.0-54-generic i686
ApportVersion: 2.20.1-0ubuntu2.6
Architecture: i386
CurrentDesktop: MATE
Date: Thu Jun 15 13:28:43 2017
InstallationDate: Installed on 2017-06-07 (7 days ago)
InstallationMedia: Ubuntu-MATE 16.04.2 LTS "Xenial Xerus" - Release i386 (20170215)
SourcePackage: linux-hwe
UpgradeStatus: No upgrade log present (probably fresh install)
summary: |
- Slow disk writes after some uptime, only on certain hw and 4.4+ kernels + Slow disk writes after some uptime, only on 32bit/16+RAM/4+ kernels |
After long hours of testing, it appears that the problem goes away with
mem=12G
or lower in the kernel command line, and appears with
mem=13G
or any other value up to 16G that the system has.
Tomorrow I'll test sysctl vm.dirty_ background_ ratio=5;
feel free to suggest more tests.