On Fri, Sep 25, 2009 at 5:24 PM, James Lever <j...@jamver.id.au> wrote: > > On 26/09/2009, at 1:14 AM, Ross Walker wrote: > >> By any chance do you have copies=2 set? > > No, only 1. So the double data going to the slog (as reported by iostat) is > still confusing me and clearly potentially causing significant harm to my > performance.
Weird then, I thought that would be an easy explaination. >> Also, try setting zfs_write_limit_override equal to the size of the >> NVRAM cache (or half depending on how long it takes to flush): >> >> echo zfs_write_limit_override/W0t268435456 | mdb -kw > > That’s an interesting concept. All data still appears to go via the slog > device, however, under heavy load my responsive to a new write is typically > below 2s (a few outliers at about 3.5s) and a read (directory listing of a > non-cached entry) is about 2s. > > What will this do once it hits the limit? Will streaming writes now be sent > directly to a txg and streamed to the primary storage devices? (that is > what I would like to see happen). It's sets the max size of a txg to the given size. When it hits that number it flushes to disk. >> As a side an slog device will not be too beneficial for large >> sequential writes, because it will be throughput bound not latency >> bound. slog devices really help when you have lots of small sync >> writes. A RAIDZ2 with the ZIL spread across it will provide much >> higher throughput then an SSD. An example of a workload that benefits >> from an slog device is ESX over NFS, which does a COMMIT for each >> block written, so it benefits from an slog, but a standard media >> server will not (but an L2ARC would be beneficial). >> >> Better workload analysis is really what it is about. > > > It seems that it doesn’t matter what the workload is if the NFS pipe can > sustain more continuous throughput the slog chain can support. Only on large sequentials, small sync IO should benefit from the slog. > I suppose some creative use of the logbias setting might assist this > situation and force all potentially heavy writers directly to the primary > storage. This would, however, negate any benefit for having a fast, low > latency device for those filesystems for the times when it is desirable (any > large batch of small writes, for example). > > Is there a way to have a dynamic, auto logbias type setting depending on the > transaction currently presented to the server such that if it is clearly a > large streaming write it gets treated as logbias=throughput and if it is a > small transaction it gets treated as logbias=latency? (i.e. such that NFS > transactions can be effectively treated as if it was local storage but > minorly breaking the benefits of the txg scheduling). I'll leave that to the Sun guys to answer. -Ross _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
