On Nov 19, 2007 9:41 AM, Roch - PAE <[EMAIL PROTECTED]> wrote: > > 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 > >
So, when are each of these solutions hitting or expected to hit Nevada? I think the second is the winner, as I see in the iostat either one or the other getting i/o at a time, and its just feels like under duress the system simply doesn't have balance anymore between reads/writes. Its like a smooth moving road with traffic in both directions. Then the construction crew arrives with flag men who only allow one direction at a time to go. > > -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
