G'Day James, Folks,

On Wed, Oct 24, 2007 at 08:17:11AM -0400, James Carlson wrote:
> Matthew Ahrens writes:
> > This case adds capability to ZFS to use storage devices as a level 2 ARC
> > (L2ARC), caching read requests that would otherwise be satisfied by disk.
> > Random read performance can then be improved by adding fast storage
> > devices to the L2ARC, such as short-stroked disks, solid state disks,
> > and other media with substantially faster read latency than disk.
> 
> 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,
where 1 to 4 SSDs currently can't compete with the sequential read
performance of 46 or so disks.  A future improvement may include smarter
load balancing between the SSDs and disks, faster SSDs, or both.  For now,
the L2ARC avoids caching data that is likely to be sequentially read,
by noting which blocks were loaded using prefetch and not caching them.
The goal is to get the best of both worlds - random I/O goes to the SSDs
while sequential I/O goes to the disks.

There is certainly still a need to examine and corfirm how the cache
devices are performing.  While the L2ARC provides kstats (zfs:::l2*) and
a summary in zpool iostat, this is probably best answered from just iostat:

# iostat -xnz 5
[...]
                    extended device statistics              
    r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device
  152.8    0.0 1222.4    0.0  0.0  1.0    0.0    6.3   0  96 c0t1d0
   13.8    0.0  110.4    0.0  0.0  0.0    0.0    0.9   0   1 c0t3d0

c0t3d0 is my SSD cache device, which is serving requests 7 times faster
than disk (and this is an old SSD).

So the approach would be:

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.

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

cheers,

Brendan

-- 
Brendan
[CA, USA]

Reply via email to