我有一个服务器与ESXi 5和iSCSI连接的networking存储。 存储服务器在8.0.4版本的Raid-Z中有4x1Tb SATA II磁盘。 这两台机器通过千兆位以太网相互连接，与其他设备隔离。 中间没有开关。 SAN盒本身是1U超微型服务器，具有3GHz的Intel Pentium D和2G内存。 磁盘连接到集成控制器（英特尔？）。
raid-z卷分为三个部分：两个zvols，与iscsi共享，一个直接在zfs之上，与nfs和类似的共享。
我ssh进入freeNAS框，并在磁盘上做了一些testing。 我用dd来testing磁盘的第三部分（直接在ZFS之上）。 我从/ dev / zero复制了一个4GB（2倍的RAM）块到磁盘，速度是80MB / s。
其他的iSCSI共享zvols是ESXi的数据存储。 我做了类似的testing与time dd ..在那里。 由于dd没有给出速度，我把时间转移的数据量除以time 。 结果是大约30-40 MB / s。 那大约是freeNAS主机的一半速度！
然后，我testing了在同一ESXi主机上运行的虚拟机上的IO。 虚拟机是一台轻巧的CentOS 6.0机器，当时并没有做任何事情。 当时没有其他的虚拟机在服务器上运行，而磁盘arrays的另外两个“部分”未被使用。 类似的ddtesting给了我约15-20 MB / s的结果。 这又是下一个结果的一半左右！
当然这是raid-z – > zfs – > zvolume – > iSCSI – > VMFS – > VM的一些开销，但是我不认为它会那么大。 我相信我的系统中一定有什么问题。
我听说freeNAS iSCSI的性能不好，是吗？ 我还没有设法让任何其他“大”的SAN操作系统在机器上运行（NexentaSTOR，openfiler）。
你能看到我的设置有任何明显的问题吗？
为了加快速度，你将需要更多的内存。 我会从这些渐进的改进开始。
首先，加快文件系统：1）ZFS需要比使用ARCcaching更多的RAM。 越多越好。 如果你可以增加至less8GB或更多，那么你应该看到一些改进。 我们有64GB的。
2）接下来，我将添加一个ZIL日志磁盘，即一个20GB左右的小型SSD驱动器。 使用SLCtypes而不是MLC。 build议使用2个ZIL磁盘冗余。 这将加速写入巨大。
3）添加一个L2ARC磁盘。 这可以包括一个好的大小的SSD，例如一个250GB的MLC驱动器将是合适的。 从技术上说，不需要L2ARC。 但是，添加大量快速SSD存储通常比更多的主存储更便宜。 但是，从尽可能多的内存开始，您可以先安装/购买。
有一些网站声称通常会帮助zfs进行调优，这些参数/variables可以通过GUI进行设置。 值得期待/尝试。
另外，请咨询freenas论坛。 你会在这里得到比你更好的支持。
其次：你可以加速networking。 如果您恰好在您的超微服务器中有多个NIC接口。 你可以把它们绑定起来，给你几乎两倍的networking吞吐量和一些冗余。 http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004088
一些build议。
我认为80兆字节/秒在FreeNAS系统上直接testing是很慢的。 您可能有磁盘问题。 您是使用“高级格式”还是4K扇区磁盘？ 如果是这样，可能会有分区alignment问题 ，将影响你的performance。
您可能看到的不是翻译开销，而是由于不同的访问模式而导致性能下降。 对ZFS卷的顺序写入将简单地创build一个接近顺序的数据stream，以写入您的底层物理磁盘。 对ZFS卷上的VMFS数据存储区进行顺序写入将创build一个数据stream，该数据stream被VMFS文件系统结构的元数据更新“刺穿”，并为此非常元数据提供频繁的同步/caching刷新请求。 由于来宾的文件系统元数据，从客户端再次对虚拟磁盘进行顺序写入将会增加对顺序stream的“穿透”。
通常在这些情况下规定的治疗将启用写入caching，其将忽略caching刷新请求。 这将缓解随机写入和同步问题，并改善您在VM guest虚拟机中看到的性能。 请记住，如果高速caching无法在断电/突然重新启动的情况下持续存在，则数据完整性将受到威胁。
您可以通过在FreeNAS框中发布类似于iostat -xd 5轻松testing您的磁盘限制，并查看基础物理设备的队列大小和利用率统计信息。 在disk device模式下运行esxtop也应该通过显示ESX端的磁盘利用率统计信息来帮助您了解正在发生的事情。
我目前使用FreeNas 8和两个Raid 5 sSataarrays连接在服务器上。 该服务器拥有8GB内存和两个单核英特尔至强处理器。
我的performance与其他人所经历的大不相同。
我没有使用MPIO或NIC上的任何负载平衡。 只有一个英特尔GIGE 10/100/1000服务器网卡。
两个arrays都有五个2.0TB硬盘，相当于大约7.5TB的空间RAID5。
我将这两个数组用于两个不同的function：
1）Array＃1连接到运行Centos 5.8和PostGres的Intel HPC服务器。 文件系统是ext4。 我已经能够获得这个arrays800 Mbps /秒的峰值。
2）arrays＃2正被用于Citrix Xenserver 6 Centos虚拟机。 这些200GB硬盘分区提供了出色的性能。 每台虚拟机都运行实时的SIP信令服务器，支持500-1000个CPS的5-10K并发呼叫。 主数据库服务器将它们复制到其表中之前，本地数据库将CDR写入这些分区。 我已经能够获得这个arrays800 Mbps /秒的峰值。
现在，我不build议使用FreeNas iSCSIarrays作为大型数据库分区的主要解决scheme。 我已经在数据库服务器上的10K RPM SAS Raid 10分区上运行了。
但是，绝对没有理由不能将您的数据stream量通过简单的交换以太网networking发送到运行FreeNAS的合理configuration的服务器，并在GIGE的理论峰值发送。
我还没有testing读取吞吐量，但RAID5读取速度较慢。 所以，它应该是一样好或更好。
随着更多的stream量需求，FreeNAS一直很好地扩展。 任何CentOS 5.8服务器都将使用自己的caching来caching数据，然后再将其发送到iSCSIarrays。 所以，请确保您的虚拟机主机上有足够的内存，您将对您的性能感到满意。
在我看来，没有什么比数据库应用程序和实时交通应用程序更好地testing技术。
我也认为添加系统内存直写cachingfunction将是有益的，但是我的性能数据显示FreeNAS和iSCSI正在performance出色！
它只能变得更好。
首先，VMware的性能不是iSCSI（FreeNAS）或NFS 3或CIFS（Windows）协议的问题，它是XFS文件系统写入和“同步”状态的问题。
FreeNAS有一个名为“同步”的属性，可以设置为开或关。 “zfs sync = always”默认情况下会被设置，并会导致每次写入都被刷新。 这极大地降低了性能，但保证了磁盘写入。 例如，在没有压力的现代设备（3.x GHZ CPU，Seagate 7200 HD，1GigEnetworking）上运行VMware ESXI 5.5和FreeNAS通常会导致VMware克隆或Windows robocopy或其他“写入”操作的性能达到4-5MB / sec 。 通过设置“zfs sync = disabled”，写入性能可轻松达到40MBs，高达80Mbs（即每秒兆字节）。 它的10倍-20倍，同步禁用更快，是你所期望的….但写入不安全。
所以，当我想要做一堆克隆或者表示robocopy等时，我使用sync = disabled'暂时'。然后我重置sync =总是用于'标准'VM操作。
FreeNAS有一个'擦洗'，将validation磁盘上的所有字节… 12TB大约需要8小时，我每周运行一次作为后续，以确保在sync =禁用期间写入的字节是OK。