ZFS L2ARC [PSARC/2007/618 FastTrack timeout 10/31/2007]

[James Carlson]

Brendan Gregg - Sun Microsystems writes:
> On Wed, Oct 24, 2007 at 08:17:11AM -0400, James Carlson wrote:
> > Is there any way to determine whether a given cache device is helping
> > or hurting me?  Perhaps some statistics that can be viewed?
> 
> The L2ARC has been designed with the aim to either improve performance,
> or do nothing.  The most acute example of this would be sequential reads,

That's good, though if it's doing nothing, then I'm not getting what I
paid for out of the faster devices and could probably use them
elsewhere.  ;-}

> 1. use iostat to determine
> 	- total IOPS
> 	- total throughput
> 	- average sevice/wait times
> 2. zpool add <pool> cache <vdev> ...
> 3. time passes
> 4. rerun iostat.  Recheck those metrics.

OK; that seems reasonable.  Thanks!

> > Any rule of thumb about choosing such a device?  How much faster than
> > main storage does it need to be in order to be useful, and does the
> > organization of main storage make a difference?  (E.g., will I get a
> > bigger bang for the buck if I add cache to RAIDZ than to mirroring?)
> 
> We are expecting cache devices to be at least 10 times faster than
> random disk performance, so we are expecting large wins to start with.
> Whether it is raidz or mirroring may certainly affect the size of the
> win, and we can build up best practices for this as we get more data
> from the prototype.

That's the sort of information I was expecting ... if some
suitably-worded hints could make it into the man page or a whitepaper,
that'd probably help cut down on the number of new service calls.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677