Strictly from a price vs. performance standpoint, the OpenSolaris ZFS server is a huge success.  The test of 4k random performance with 66% writes and 33% reads is one that really excites us.  We have historically graphed a lot of performance data about our cloud environment using MRTG, and this test most accurately describes our real world access patterns in our web hosting environment.  At a load of 33, OpenSolaris logged nearly triple the performance compared to the Promise M610i.  If we can deploy the OpenSolaris box into production and actually see this level of performance, we will be thrilled. 

We will obviously consider using Nexenta because Nexenta has the LED’s and notifications working.  Nexenta did not deliver as much performance as OpenSolaris did.  In the 4k random 66% write 33% read test, Nexenta Enterprise managed to deliver about 90% of the performance of unmodified OpenSolaris.  In some 32k tests, Nexenta delivered even less performance.  It is tough to justify the cost of the Nexenta Enterprise license when it performs slower than free OpenSolaris.  If you need a support path, then Nexenta Enterprise may be worth it.

When we started this project, our goal was to build a ZFS based storage solution that could match the price of a Promise M610i SAN, yet measurably exceed the performance.  We believe we have succeeded in doing exactly that.  Our ZFS server can be built for about the same price as the Promise M610i.  The performance of the OpenSolaris ZFS server at high loads was anywhere from double to quadruple the performance of the Promise solution in most tests at nearly the same cost.  We deploy additional SAN boxes each year.  Based on the performance of this test, our next SAN boxes will be ZFS based.

Things We Would Have Done Differently
Comments Locked

102 Comments

View All Comments

  • MGSsancho - Tuesday, October 5, 2010 - link

    I haven't tried this myself yet but how about using 8kb blocks and using jumbo frames on your network? possibly lower through padding to fill the 9mb packet in exchange for lower latency? I have no idea as this is just a theory. dudes in the #opensolaris irc chan have always recommended 128K or 64K depending on the data.
  • solori - Wednesday, October 20, 2010 - link

    One easy way to check this would be to export the pool from OpenSolaris and directly import it to NexentaStor and re-test. I think you'll find that the differences - as your benchmarks describe - are more linked to write caching at the disk level than partition alignment.

    NexentaStor is focused on data integrity, and tunes for that very conservatively. Since SATA disks are used in your system, NexentaStor will typically disable disk write cache (write hit) and OpenSolaris may typically disable device cache flush operations (write benefit). These two feature differences can provide the benchmark differences you're seeing.

    Also, some "workstation" tuning includes the disabling of ZIL (performance benefit). This is possible - but not recommended - in NexentaStor but has the side effect of risking application data integrity. Disabling the ZIL (in the absence of SLOG) will result in synchronous writes being committed only with transaction group commits - similar performance to having a very fast SLOG (lots of ARC space helpful too).
  • fmatthew5876 - Tuesday, October 5, 2010 - link

    I'd be very interested to see how FreeBSD ZFS benchmark results would compare to Nexenta and Open Solaris.
  • mbreitba - Tuesday, October 5, 2010 - link

    We have benchmarked FreeNAS's implimentation of ZFS on the same hardware, and the performance was abysmal. We've considered looking into the latest releases of FreeBSD but have not completed any of that testing yet.
  • jms703 - Tuesday, October 5, 2010 - link

    Have you benchmarked FreeBSD 8.1? There were a huge number of performance fixes in 8.1.

    Also, when was this article written? OpenSolaris was killed by Sun on August 13th, 2010.
  • mbreitba - Tuesday, October 5, 2010 - link

    There was a lot of work on this article just prior to the official announcement. The development of the Illumos foundation and subsequent OpenIndiana has been so rapidly paced that we wanted to get this article out the door before diving in to OpenIndiana and any other OpenSolaris derivatives. We will probably add more content talking about the demise of OpenSolaris and the Open Source alternatives that have started popping up at a later date.
  • MGSsancho - Tuesday, October 5, 2010 - link

    Not to mention that projects like illumos are currently not recommended for production, Currently only meant as a base for other distros (OpenIndiana.) Then there is Solaris 11 due soon. I'll try out the express version when its released.
  • cdillon - Tuesday, October 5, 2010 - link

    FreeNAS 0.7.x is still using FreeBSD 7.x, and the ZFS code is a bit dated. FreeBSD 8.x has newer ZFS code (v15). Hopefully very soon FreeBSD 9.x will have the latest ZFS code (v24).
  • piroroadkill - Tuesday, October 5, 2010 - link

    This is relevant to my interests, and I've been toying with the idea of setting up a ZFS based server for a while.

    It's nice to see the features it can use when you have the hardware for it.
  • cgaspar - Tuesday, October 5, 2010 - link

    You say that all writes go to a log in ZFS. That's just not true. Only synchronous writes below a certain size go into the log (either built into the pool, or a dedicated log device). All writes are held in memory in a transaction group, and that transaction group is written to the main pool at least every 10 seconds by default (in OpenSolaris - it used to be 30 seconds, and still is in Solaris 10 U9). That's tunable, and commits will happen more frequently if required, based on available ARC and data churn rate. Note that _all_ writes go into the transaction group - the log is only ever used if the box crashes after a synchronous write and before the txg commits.

    Now for the caution - you have chosen SSDs for your SLOG that don't have a backup power source for their on board caches. If you suffer power loss, you may lose data. Several SLC SSDs have recently been released that have a supercapacitor or other power source sufficient to write cache data to flash on power loss, but the current Intel like up doesn't have it. I believe the next generation Intel SSDs will.

Log in

Don't have an account? Sign up now