SSD磁盘和10 Gbe网络的iSCSI性能不佳

iSCSI目标

带有16 GB RAM和16个核心CPU的Ubuntu 14.04（Trusty Tahr）作为LVM支持的iSCSI目标，使用三个Samsung 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

凡sdd在硬件配置RAID 0使用三个三星850固态硬盘EVO。

发起人

我在具有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和通过网络进行操作时，性能会显着下降，我预计IOPS至少为10k。

目标与启动器之间的通信少于1 ms，iperf的网络吞吐量为9.2 Gbit / s。

我知道4k写入会对性能产生影响，因为每个数据在写入磁盘之前都必须经过启动器和目标的网络堆栈，但这从65k下降到2k是不可接受的。

问题出在哪里？我在目标和启动器之间有一个10 Gbit / s以太网 NIC。有任何想法吗？

— 凯文·帕克
source

没有足够的信息，我们的水晶球太昂贵了，无法浪费给非付费客户。如果您需要帮助，请提供有意义的信息，以帮助您确定问题。

— TomTom

我已经编辑了我的问题，如果您有时间可以帮助我提出建议。

— 凯文·帕克

由于NIC和CPU可能是任何软件iSCSI设置中的瓶颈，因此您可能要提及它们的含义。

— rakslice 2015年

简短的回答：这是网络延迟的结果和一个串行工作量（如您征收使用direct=1，sync=1和iodepth=1）。

龙回答：使用direct=1，sync=1并iodepth=1创建了一个串行的工作量，作为致力于前面的写之前新写入不能排队和确认。换句话说，写入提交速率严格取决于网络延迟。ping两台机器之间的简单间隔很可能超过0.2毫秒，在使用更高级别的协议作为TCP（以及在其之上的iSCSI）时更是如此。假设总网络延迟大约为0.33ms，那么您的最大IOPS值大约为3000。这没有考虑其他延迟源（例如磁盘本身），因此它与您记录的内容一致。

尝试以下操作：在不使用的情况下执行第一个基准测试--direct=1 --sync=1，并在使用这些选项的情况下执行另一个基准测试，但将iodepth请求增加到32个。然后在这里报告结果。

— Shodanshok
source