On Wed, 24 Jun 2009, Richard Elling wrote:
"The new code keeps track of the amount of data accepted in a TXG and the
time it takes to sync. It dynamically adjusts that amount so that each TXG
sync takes about 5 seconds (txg_time variable). It also clamps the limit to
no more than 1/8th of physical memory."
hmmm... methinks there is a chance that the 1/8th rule might not work so well
for machines with lots of RAM and slow I/O. I'm also reasonably sure that
that sort of machine is not what Sun would typically build for performance
lab
testing, as a rule. Hopefully Roch will comment when it is morning in
Europe.
Slow I/O is relative. If I install more memory does that make my I/O
even slower?
I did some more testing. I put the input data on a different drive
and sent application output to the ZFS pool. I no longer noticed any
stalls in the execution even though the large ZFS flushes are taking
place. This proves that my application is seeing stalled reads rather
than stalled writes.
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