☰

SSD 磁盘和 10 Gbe 网络的 iSCSI 性能较差

tag-icon • tag-icon linux iscsi ssd open-iscsi
SSD 磁盘和 10 Gbe 网络的 iSCSI 性能较差

iSCSI 目标

Ubuntu 14.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

sdd硬件中配置的位置RAID 0使用三块三星 850 EVO SSD。

发起者

我在具有 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 的下降是不可接受的。

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

答案1

简短回答：这是网络延迟的结果和串行工作负载（正如您使用direct=1、sync=1和所施加的iodepth=1）。

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

尝试这个：执行第一个不使用的基准测试--direct=1 --sync=1，然后执行另一个使用这些选项但将iodepth请求数增加到 32 的基准测试。然后在此处报告结果。

相关内容