You have un balance setup Fc 4gbps vs 10gbps nic After 10b/8b encoding it is even worse, but this not yet impact your benchmark yet
Sent from my iPad Hung-Sheng Tsao ( LaoTsao) Ph.D On Jun 7, 2011, at 5:46 PM, Phil Harman <phil.har...@gmail.com> wrote: > On 07/06/2011 20:34, Marty Scholes wrote: >> I'll throw out some (possibly bad) ideas. > > Thanks for taking the time. > >> Is ARC satisfying the caching needs? 32 GB for ARC should almost cover the >> 40GB of total reads, suggesting that the L2ARC doesn't add any value for >> this test. >> >> Are the SSD devices saturated from an I/O standpoint? Put another way, can >> ZFS put data to them fast enough? If they aren't taking writes fast enough, >> then maybe they can't effectively load for caching. Certainly if they are >> saturated for writes they can't do much for reads. > > The SSDs are barely ticking over, and can deliver almost as much throughput > as the current SAN storage. > >> Are some of the reads sequential? Sequential reads don't go to L2ARC. > > That'll be it. I assume the L2ARC is just taking metadata. In situations such > as mine, I would quite like the option of routing sequential read data to the > L2ARC also. > > I do notice a benefit with a sequential update (i.e. COW for each block), and > I think this is because the L2ARC satisfies most of the metadata reads > instead of having to read them from the SAN. > >> What does iostat say for the SSD units? What does arc_summary.pl (maybe >> spelled differently) say about the ARC / L2ARC usage? How much of the SSD >> units are in use as reported in zpool iostat -v? > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
