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? 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
