Ross Walker wrote:
On Nov 1, 2010, at 5:09 PM, Ian D <rewar...@hotmail.com> wrote:
Maybe you are experiencing this:
http://opensolaris.org/jive/thread.jspa?threadID=11942
It does look like this... Is this really the expected behaviour? That's just
unacceptable. It is so bad it sometimes drop connection and fail copies and
SQL queries...
Then set the zfs_write_limit_override to a reasonable value.
Depending on the speed of your ZIL and/or backing store (for async IO) you will
need to limit the write size in such a way so TXG1 is fully committed before
TXG2 fills.
Myself, with a RAID controller with a 512MB BBU write-back cache I set the
write limit to 512MB which allows my setup to commit-before-fill.
It also prevents ARC from discarding good read cache data in favor of write
cache.
Others may have a good calculation based on ARC execution plan timings, disk
seek and sustained throughput to give an accurate figure based on one's setup,
otherwise start with a reasonable value, say 1GB, and decrease until the pauses
stop.
-Ross
If this is the root cause, it sounds like some default configuration
parameters need to be calculated, determined and adjusted differently
from how they are now. It is highly preferable that the default
parameters do not exhibit severe problems. Defaults should offer
stability and performance to the extent that stability is not
compromised. (I.e. no dedupe by default under its current state).
(Manually tweaked parameters are a different story in that they should
allow a knowledgeable user to get a little more performance even if that
is more risky).
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
