On Mon, 31 May 2010, Sandon Van Ness wrote:
6586537 async zio taskqs can block out userland commands
Bob
I am using opensolaris snv_134:
r...@opensolaris: 01:32 PM :~# uname -a
SunOS opensolaris 5.11 snv_134 i86pc i386 i86pc
Is there a setting that to change the cpu scheduler for the ZFS process
or is it supposed to just be fixed out of the box? I figure if the
parity calculation process can be 'reniced' or something this problem
could likely be fixed as it ended up being CPU and not disk I/O like I
originally thought.
There are multiple factors at work. Your OpenSolaris should be new
enough to have the fix in which the zfs I/O tasks are run in in a
scheduling class at lower priority than normal user processes.
However, there is also a throttling mechanism for processes which
produce data faster than can be consumed by the disks. This
throttling mechanism depends on the amount of RAM available to zfs and
the write speed of the I/O channel. More available RAM results in
more write buffering, which results in a larger chunk of data written
at the next transaction group write interval. The maximum size of a
transaction group may be configured in /etc/system similar to:
* Set ZFS maximum TXG group size to 2684354560
set zfs:zfs_write_limit_override = 0xa0000000
If the transaction group is smaller, then zfs will need to write more
often. Processes will still be throttled but the duration of the
delay should be smaller due to less data to write in each burst. I
think that (with multiple writers) the zfs pool will be "healthier"
and less fragmented if you can offer zfs more RAM and accept some
stalls during writing. There are always tradeoffs.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
