iSCSI目标
Ubuntu14.04(Trusty Tahr)具有16 GB RAM和16核cpu作为LVM支持的iSCSI目标,使用三个三星SSD磁盘,每个磁盘使用带有板载缓存的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
使用三个Samsung 850 EVO SSD在硬件RAID 0中配置sdd的位置.
引发剂
我在具有32 GB RAM和8个核心cpu的Ubuntu 14.04客户端上导出了500G LUN.
导出LUN的基准测试
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和通过网络时,性能显着下降,我预计至少有10k IOPS.
目标和启动器之间的通信小于1毫秒,而iperf显示网络吞吐量为9.2 Gbit / s.
我知道4k写入会对性能产生影响,因为每个数据在写入磁盘之前必须通过启动器和目标的网络堆栈,但这是从65k到2k的不可接受的下降.
问题出在哪里？我在目标和启动器之间有一个10Gbit/s Ethernet NIC.有任何想法吗？
解决方法
简短回答：这是网络延迟和串行工作负载的结果(通过使用direct = 1,sync = 1和iodepth = 1强制执行).
答案很长：使用direct = 1,sync = 1和iodepth = 1,您创建了一个串行工作负载,因为在上一次写入提交和确认之前,新写入不能排队.换句话说,写入提交率严格依赖于网络延迟.两台机器之间的简单ping可以超过0.2ms,当使用更高级别的协议作为TCP(以及其上面的iSCSI)时更是如此.假设总网络延迟大约为0.33ms,则最大IOPS值约为3000.这不考虑其他延迟源(es：磁盘本身),因此它与您记录的内容一致.
试试这个：执行第一个没有–direct = 1 –sync = 1的基准测试,另一个使用这些选项,但是将iodepth增加到32个请求.然后在这里报告结果.
