On Thu, Apr 23, 2009 at 06:07:06AM -0700, Dearl Neal wrote: > I have been testing the performance of zfs vs. ufs using filebench. > The setup is a v240, 4GB RAM, 2...@1503mhz, 1 320GB _SAN_ attached LUN, > and using a ZFS mirrored root disk. Our SAN is a top notch NVRAM > based SAN.
Can you give any additional details about your SAN configuration? > There are lots of discussions using ZFS with SAN based storage.. and > it seems ZFS is designed to perform best with dumb disk (JBODs). The > test I ran support this observation.. and no matter what kernel > tunables I make the zfs_params, I would reccomend against setting kernel tunables until you've exhausted all other alternatives. There are some straight-forward per-ZFS-filesystem configuration variables that can make a big difference. > I just can't seem to get the performance from ZFS that I can get out > of UFS under the Solaris Volume Manager (SVM). > One interesting test revealed better performance using the SMI label > on our LUNs than that EFI label. This is true for using the > fileserver, large_db_oltp_8k_uncached, and large_db_oltp_8k_cached > workloads from filebench. If you're running a bunch of tests that perform 8k reads and writes, UFS may look better out of the box. On UFS, the filesystem's blocksize is 8k. By default ZFS uses 128k blocks. However, you can tune this to the block size that is optimal for your workload. (Generally a tuning that's relevant to database workloads.) The catch is that if you change the record size for an existing filesystem, only new data will be written with the new blocksize. If you haven't tried this already, you might tune the recordsize to 8k, if you're testing database workloads, and then re-generate your test dataset. If this is indeed part of your performance problem, you should see substantially better numbers. http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide The Best Practices Guide also has some helpful information about how to setup ZFS for your particular configuration and workload. If you haven't seen this already, it might be useful too. -j _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org