Dickon Hood writes: > On Fri, Dec 07, 2007 at 13:14:56 +0000, I wrote: > : On Fri, Dec 07, 2007 at 12:58:17 +0000, Darren J Moffat wrote: > : : Dickon Hood wrote: > : : >On Fri, Dec 07, 2007 at 12:38:11 +0000, Darren J Moffat wrote: > : : >: Dickon Hood wrote: > > : : >: >We're seeing the writes stall in favour of the reads. For normal > : : >: >workloads I can understand the reasons, but I was under the > impression > : : >: >that real-time processes essentially trump all others, and I'm > surprised > : : >: >by this behaviour; I had a dozen or so RT-processes sat waiting for > disc > : : >: >for about 20s. > > : : >: Are the files opened with O_DSYNC or does the application call fsync ? > > : : >No. O_WRONLY|O_CREAT|O_LARGEFILE|O_APPEND. Would that help? > > : : Don't know if it will help, but it will be different :-). I suspected > : : that since you put the processes in the RT class you would also be doing > : : synchronous writes. > > : Right. I'll let you know on Monday; I'll need to restart it in the > : morning. > > I was a tad busy yesterday and didn't have the time, but I've switched one > of our recorder processes (the one doing the HD stream; ~17Mb/s, > broadcasting a preview we don't mind trashing) to a version of the code > which opens its file O_DSYNC as suggested. > > We've gone from ~130 write ops per second and 10MB/s to ~450 write ops per > second and 27MB/s, with a marginally higher CPU usage. This is roughly > what I'd expect. > > We've artifically throttled the reads, which has helped (but not fixed; it > isn't as determinative as we'd like) the starvation problem at the expense > of increasing a latency we'd rather have as close to zero as possible. > > Any ideas? >
O_DSYNC was good idea. Then if you have recent Nevada you can use the separate intent log (log keyword in zpool create) to absord those writes without having splindle competition with the reads. Your write workload should then be well handled here (unless the incoming network processing is itself delayed). -r > Thanks. > > -- > Dickon Hood > > Due to digital rights management, my .sig is temporarily unavailable. > Normal service will be resumed as soon as possible. We apologise for the > inconvenience in the meantime. > > No virus was found in this outgoing message as I didn't bother looking. > > _______________________________________________ > 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
