On Wed, Oct 24, 2007 at 03:13:01PM -0400, James Carlson wrote: > 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. ;-}
Hopefully it will be a non-issue since it's intended for random read workloads where it will be active. This can be improved later as we see how it responds to other workloads. Perhaps in the best practices it could note that if your readzilla disks are always idle, then you should consider making them logzilla instead. :) > > > 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. Understood; there is definately room for confusion with this, especially as it's a cache that nothing evicts directly to (as it feeds asynchronously rather than evicting-to synchronously). The man page can have updates down the road, and I'll certainly create a whitepaper/article/blog/whatever that stepped through clear and sufficient detail. thanks, Brendan -- Brendan [CA, USA]
