Neil Perrin writes:
>
>
> Joe Little wrote:
> > On Nov 16, 2007 9:13 PM, Neil Perrin <[EMAIL PROTECTED]> wrote:
> >> Joe,
> >>
> >> I don't think adding a slog helped in this case. In fact I
> >> believe it made performance worse. Previously the ZIL would be
> >> spread out over all devices but now all synchronous traffic
> >> is directed at one device (and everything is synchronous in NFS).
> >> Mind you 15MB/s seems a bit on the slow side - especially is
> >> cache flushing is disabled.
> >>
> >> It would be interesting to see what all the threads are waiting
> >> on. I think the problem maybe that everything is backed
> >> up waiting to start a transaction because the txg train is
> >> slow due to NFS requiring the ZIL to push everything synchronously.
> >>
> >
> > I agree completely. The log (even though slow) was an attempt to
> > isolate writes away from the pool. I guess the question is how to
> > provide for async access for NFS. We may have 16, 32 or whatever
> > threads, but if a single writer keeps the ZIL pegged and prohibiting
> > reads, its all for nought. Is there anyway to tune/configure the
> > ZFS/NFS combination to balance reads/writes to not starve one for the
> > other. Its either feast or famine or so tests have shown.
>
> No there's no way currently to give reads preference over writes.
> All transactions get equal priority to enter a transaction group.
> Three txgs can be outstanding as we use a 3 phase commit model:
> open; quiescing; and syncing.
That makes me wonder if this is not just the lack of write
throttling issue. If one txg is syncing and the other is
quiesced out, I think it means we have let in too many
writes. We do need a better balance.
Neil is it correct that reads never hit txg_wait_open(), but
they just need an I/O scheduler slot ?
If so seems to me just a matter of
6429205 each zpool needs to monitor it's throughput and throttle heavy
writers
However, if this is it, disabling the zil would not solve the
issue (it might even make it worse). So I am lost as to
what could be blocking the reads other than lack of I/O
slots. As another way to improve I/O scheduler we have :
6471212 need reserved I/O scheduler slots to improve I/O latency of
critical ops
-r
>
> Neil.
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
