Tag: NFS ops/sec

Latest SPECsfs2008 results, over 1 million NFS ops/sec – chart-of-the-month

Posted on by Ray in Clustered storage, Ethernet, File Storage, NFS throughput, SPECsfs, SPECsfs2008, SSD storage, Storage drive, Storage performance, System effectiveness
Column chart showing the top 10 NFS througput operations per second for SPECsfs2008
(SCISFS111221-001) (c) 2011 Silverton Consulting, All Rights Reserved

[We are still catching up on our charts for the past quarter but this one brings us up to date through last month]

There’s just something about a million SPECsfs2008(r) NFS throughput operations per second that kind of excites me (weird, I know).  Yes it takes over 44-nodes of Avere FXT 3500 with over 6TB of DRAM cache, 140-nodes of EMC Isilon S200 with almost 7TB of DRAM cache and 25TB of SSDs or at least 16-nodes of NetApp FAS6240 in Data ONTAP 8.1 cluster mode with 8TB of FlashCache to get to that level.

Nevertheless, a million NFS throughput operations is something worth celebrating.  It’s not often one achieves a 2X improvement in performance over a previous record.  Something significant has changed here.

The age of scale-out

We have reached a point where scaling systems out can provide linear performance improvements, at least up to a point.  For example, the EMC Isilon and NetApp FAS6240 had a close to linear speed up in performance as they added nodes indicating (to me at least) there may be more there if they just throw more storage nodes at the problem.  Although maybe they saw some drop off and didn’t wish to show the world or potentially the costs became prohibitive and they had to stop someplace.   On the other hand, Avere only benchmarked their 44-node system with their current hardware (FXT 3500), they must have figured winning the crown was enough.

However, I would like to point out that throwing just any hardware at these systems doesn’t necessary increase performance.  Previously (see my CIFS vs NFS corrected post), we had shown the linear regression for NFS throughput against spindle count and although the regression coefficient was good (~R**2 of 0.82), it wasn’t perfect. And of course we eliminated any SSDs from that prior analysis. (Probably should consider eliminating any system with more than a TB of DRAM as well – but this was before the 44-node Avere result was out).

Speaking of disk drives, the FAS6240 system nodes had 72-450GB 15Krpm disks, the Isilon nodes had 24-300GB 10Krpm disks and each Avere node had 15-600GB 7.2Krpm SAS disks.  However the Avere system also had a 4-Solaris ZFS file storage systems behind it each of which had another 22-3TB (7.2Krpm, I think) disks.  Given all that, the 16-node NetApp system, 140-node Isilon and the 44-node Avere systems had a total of 1152, 3360 and 748 disk drives respectively.   Of course, this doesn’t count the system disks for the Isilon and Avere systems nor any of the SSDs or FlashCache in the various configurations.

I would say with this round of SPECsfs2008 benchmarks scale-out NAS systems have come out.  It’s too bad that both NetApp and Avere didn’t release comparable CIFS benchmark results which would have helped in my perennial discussion on CIFS vs. NFS.

But there’s always next time.

~~~~

The full SPECsfs2008 performance report went out to our newsletter subscriber’s last December.  A copy of the full report will be up on the dispatches page of our site sometime later this month (if all goes well). However, you can see our full SPECsfs2008 performance analysis now and subscribe to our free monthly newsletter to receive future reports directly by just sending us an email or using the signup form above right.

For a more extensive discussion of file and NAS storage performance covering top 30 SPECsfs2008 results and NAS storage system features and functionality, please consider purchasing our NAS Buying Guide available from SCI’s website.

As always, we welcome any suggestions on how to improve our analysis of SPECsfs2008 results or any of our other storage system performance discussions.

Comments?

Latest SPECsfs2008 results – chart of the month

Posted on by Ray in File Storage, NFS throughput, SPECsfs, SPECsfs2008, Storage, Storage performance
(SCISFS110318-003) (c) 2011 Silverton Consulting, Inc., All Rights Reserved
(SCISFS110318-003) (c) 2011 Silverton Consulting, Inc., All Rights Reserved

The above chart comes from our last month’s newsletter on the lastest SPECsfs2008 file system performance benchmark results and depicts a scatter plot of system NFS throughput operations per second versus the number of disk drives in the system being tested.  We eliminate from this chart any system that makes use of Flash Cache/SSDS or any other performance use of NAND (See below on why SONAS was still included).

One constant complaint of benchmarks is that system vendors can just throw hardware at the problem to attain better results.   The scatter plot above is one attempt to get to the truth in that complaint.

The regression equation shows that NFS throughput operations per second = 193.68*(number of disk drives) + 23834. The regression coefficient (R**2) is 0.87 which is pretty good but not exactly perfect. So given these results, one would have to conclude there is some truth in the complaint but it doesn’t tell the whole story. (Regardless of how much it pains me to admit it).

A couple of other interesting things about the chart:

  • IBM released a new SONAS benchmark with 1975 disks, with 16 interface and 10 storage nodes to attain its 403K NFS ops/second. Now the SONAS had 512GB of NV Flash, which I assume is being used for redundancy purposes on writes and not as a speedup for read activity. Also the SONAS system complex had over 2.4TB of cache (includes the NV Flash).  So there was a lot of cache to throw at the problem.
  • HP BL860c results were from a system with 1480 drives, 4 nodes (blades) and ~800GB of cache to attain its 333KNFS ops/second.

(aside) Probably need to do a chart like this with amount of cache as the x variable (/aside)

In the same report we talked about the new #1 performing EMC VNX Gateway  that used 75TB of SAS-SSDs and 4 VNX5700’s as its backend. It was able to reach 497K NFS ops/sec.   It doesn’t show up on this chart because of its extensive use of SSDs.  But according to the equation above one would need to use ~2500 disk drives to attain similar performance without SSDS and I believe, a whole lot of cache.

—-

The full performance dispatch will be up on our website after the middle of next month (I promise) but if one is interested in seeing it sooner sign up for our free monthly newsletter (see subscription request, above right) or subscribe by email and we will send the current issue along with download instructions for this and other reports.  If you need an even more in-depth analysis of NAS system performance please consider purchasing SCI’s NAS Buying Guide also available from our website.

As always, we welcome any constructive suggestions on how to improve any of our storage performance analysis.

Comments?

 

SCI’s latest SPECsfs2008 NFS ops vs. system size – chart of the month

Posted on by Ray in File Storage, NFS throughput, SPECsfs, SPECsfs2008, Storage, Storage architecture, Storage performance
(c) 2011 Silverton Consulting, Inc., All Rights Reserved
(c) 2011 Silverton Consulting, Inc., All Rights Reserved

We return to our periodic discussion of storage system performance, this time on SPECsfs(r)2008 benchmark results for NFS file serving ops per second vs. system reported memory size.  For some obscure reason, I was very intrigued with this chart.

Chart description

We have broken the data out to show those system that only used DRAM in system memory with only hard disk drives and those systems that also included either NAND cache in system memory or SSDs.  Current SPECsfs2008 results show 33 systems with DRAM and disk drives and only 6 using SSDs or NAND cache for NFS results.

The horizontal axis shows system memory size for the systems under test and doesn’t include SSD capacity (considered drive capacity by SPECsfs2008) size but does include NAND cache size (considered system memory by SPECsfs2008).  The vertical axis shows maximum NFS throughput operations per second attained by the storage.  The two lines are Excel generated linear regressions across the two sets of data (DRAM-Disk only systems and SSD or NAND caching systems).

Discussion of results

Given the limited data we probably can’t conclude much from the SSD-NAND linear regression line other than it’s different and somewhat less than what can be gained on average from a system using DRAM and disk only.  Also the regression coefficient (R**2) of either linear regression is not that great (~0.62 for DRAM-Disk only and ~0.69 for SSD or NAND use) which might be stretching any real discussion based on statistical normalcy. Nevertheless, one question that emerges is why would SSD or NAND use not generate an relatively equivalent amount of NFS throughput as systems with DRAM only?

Obviously, NAND-SSDs access times are not as fast as DRAM.  Thus, if I had 800GB of DRAM, I could potentially access data faster than if I had 800GB of NAND cache or SSDs, all things being equal.   However, when talking about access time frames at the sub-msec level one would think it wouldn’t make that much of a difference, but apparently it does.

Also, given the limited data on SSDs vs. NAND cache use, it’s hard to make any distinction between these two types of systems but one can hope that as more data comes in, we can answer this as well.  Another question is whether SSD capacity should be considered system memory or drive capacity for benchmark purposes.  SPECsfs2008 states that SSD size should be considered drive capacity but that’s open to some debate which more data could help resolve.

Finally, missing from SPECsfs2008 reports is any statement of system cost.  As such, it’s impossible to add any measure of relative cost effectiveness factor to this discussion. However, given the current price differential (on $/GB) between DRAM and NAND memory or SSD capacity, one could probably conclude that on a cost effectiveness basis the relative advantages of DRAM only systems might diminish.  But without system cost information that’s difficult to quantify.

—-

The full performance dispatch will be up on our website after month end but if one is interested in seeing it sooner sign up for our free monthly newsletter (see subscription widget, above right) or subscribe by email and we will send the current issue along with download instructions for this and other reports.  If you need an even more in-depth analysis of NAS system performance please consider purchasing SCI’s NAS Buying Guide also available from our website.

As always, we welcome any constructive suggestions on how to improve any of our storage performance analysis.

Comments?