iSCSI目标
具有16 GB RAM和16核CPU的Ubuntu 14.04 （Trusty Tahr）作为LVM支持的iSCSI目标，使用三个三星SSD磁盘，每个SSD都可以使用具有板载高速caching的LSI 6 Gbit / s控制器执行65k IOPS。
目标SSD盘上的基准：
fio --filename=/dev/sdd --direct=1 --sync=1 --rw=write --bs=4k --numjobs=10 --iodepth=1 --runtime=60 --time_based --group_reporting --name=ssd-max iops=65514 其中sdd使用三个三星850 EVO固态硬盘在硬件RAID 0中进行configuration。
引发剂
我在Ubuntu 14.04客户端上导出了一个500G的LUN，内存为32GB RAM和8个核心CPU。
对导出的LUN进行基准testing
fio --filename=/dev/sdg --direct=1 --sync=1 --rw=write --bs=4k --numjobs=10 --iodepth=1 --runtime=60 --time_based --group_reporting --name=client-max iops=2400
在做DAS和networking时，性能会有明显的下降，我预计至less有10k IOPS。
目标和发起者之间的通信小于1 ms，iperf显示9.2 Gbit / s的networking吞吐量。
据我所知，4k写入会对性能产生影响，因为在写入磁盘之前，每个数据都必须经过启动器和目标的networking堆栈，但这是从65k到2k的不可接受的下降。
问题在哪里？ 目标和发起者之间有一个10 Gbit / s以太网卡 。 有任何想法吗？
简答：这是networking延迟和串行工作负载的结果（正如您使用direct=1 ， sync=1和iodepth=1 ）。
长答案：使用direct=1 ， sync=1和iodepth=1您创build了一个串行工作负载，因为新的写入不能在提交和确认上一个写入之前排队。 换句话说，写入提交率严格取决于networking延迟。 两台机器之间的简单ping可以超过0.2ms，而在使用更高级别的协议（比如iSCSI）时更是如此。 假设总networking延迟约为0.33ms，则最大IOPS值约为3000.这不包括其他延迟源（即：磁盘本身），因此它与您logging的内容一致。
试试这个：执行一个没有--direct=1 --sync=1的第一个基准testing，而另外一个select了这些选项，但增加了iodepth到32个请求。 然后在这里报告结果。