> 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.
There is a bug in the database about reads blocked by writes which may be related: http://bugs.opensolaris.org/view_bug.do?bug_id=6471212 The symptom is sometimes reducing queue depth makes read perform better. > > 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-discu > ss -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
