Hi
CC to Nick and Jan
We've seen multiple performance regressions linked to the lower(20%)
dirty_ratio. When performing enough IO to overwhelm the background
flush daemons the percent of dirty pagecache memory quickly climbs
to the new/lower dirty_ratio value of 20%. At that point all writing
processes are forced to stop and write dirty pagecache pages back to disk.
This causes performance regressions in several benchmarks as well as causing
a noticeable overall sluggishness. We all know that the dirty_ratio is
an integrity vs performance trade-off but the file system journaling
will cover any devastating effects in the event of a system crash.
Increasing the dirty_ratio to 40% will regain the performance loss seen
in several benchmarks. Whats everyone think about this???
In past, Jan Kara also claim the exactly same thing.
Subject: [LSF/VM TOPIC] Dynamic sizing of dirty_limit
Date: Wed, 24 Feb 2010 15:34:42 +0100
> (*) We ended up increasing dirty_limit in SLES 11 to 40% as it used to be
> with old kernels because customers running e.g. LDAP (using BerkelyDB
> heavily) were complaining about performance problems.
So, I'd prefer to restore the default rather than both Redhat and SUSE apply exactly
same distro specific patch. because we can easily imazine other users will face the same
issue in the future.