问题
Linux iSCSI 启动器在写入 NetApp FAS 目标并公开一堆 LUN 时，服务时间过长。在哪里查找原因以及如何解决此问题？
再生产
我正在使用sysstat 包中的iostats数据sa来计算“await”——特定请求的平均等待时间：
dd if=/dev/urandom of=test bs=8K count=1000000 & iostat -xdm 5 sdy dm-26
[...]
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sdy 0.00 1115.60 0.10 47.50 0.00 7.94 341.68 1.63 34.05 2.00 9.52
dm-26 0.00 0.00 0.10 2032.90 0.00 7.94 8.00 328.10 161.39 0.05 9.52
在这种情况下，“await”的预期值将比 测量的值低一个数量级iostats。上述样本时间段内传输的 10 秒网络流量为可在 CloudShark 上使用.dm-26是承载文件系统（单磁盘 NSS 卷）的设备映射器设备，指的是sdy“物理”设备。
环境
发起方和目标位于同一子网中。发起方主机的 IP 为 192.168.20.72，目标是 192.168.20.33，流量交换为 1GbE，启用了巨型帧（并通过网络跟踪确认正在使用），启用了 iSCSI 即时数据（并且根据所述跟踪正在使用），未启用摘要。
iSCSI 会话信息：
iscsiadm -m session -P 3
iSCSI Transport Class version 2.0-870
version 2.0-873.suse
Target: iqn.1992-08.com.netapp:sn.151745715
Current Portal: 192.168.20.33:3260,2003
Persistent Portal: 192.168.20.33:3260,2003
**********
Interface:
**********
Iface Name: default
Iface Transport: tcp
Iface Initiatorname: iqn.2015-06.de.example.dom:01:gw-cl-07
Iface IPaddress: 192.168.20.72
Iface HWaddress: <empty>
Iface Netdev: <empty>
SID: 1
iSCSI Connection State: LOGGED IN
iSCSI Session State: LOGGED_IN
Internal iscsid Session State: NO CHANGE
*********
Timeouts:
*********
Recovery Timeout: 120
Target Reset Timeout: 30
LUN Reset Timeout: 30
Abort Timeout: 15
*****
CHAP:
*****
username: <empty>
password: ********
username_in: <empty>
password_in: ********
************************
Negotiated iSCSI params:
************************
HeaderDigest: None
DataDigest: None
MaxRecvDataSegmentLength: 262144
MaxXmitDataSegmentLength: 65536
FirstBurstLength: 65536
MaxBurstLength: 65536
ImmediateData: Yes
InitialR2T: No
MaxOutstandingR2T: 1
************************
Attached SCSI devices:
************************
Host Number: 3 State: running
scsi3 Channel 00 Id 0 Lun: 0
Attached scsi disk sdb State: running
scsi3 Channel 00 Id 0 Lun: 1
Attached scsi disk sdc State: running
scsi3 Channel 00 Id 0 Lun: 10
Attached scsi disk sdl State: running
scsi3 Channel 00 Id 0 Lun: 11
Attached scsi disk sdm State: running
scsi3 Channel 00 Id 0 Lun: 12
Attached scsi disk sdn State: running
scsi3 Channel 00 Id 0 Lun: 13
Attached scsi disk sdo State: running
scsi3 Channel 00 Id 0 Lun: 14
Attached scsi disk sdp State: running
scsi3 Channel 00 Id 0 Lun: 15
Attached scsi disk sdq State: running
scsi3 Channel 00 Id 0 Lun: 16
Attached scsi disk sdr State: running
scsi3 Channel 00 Id 0 Lun: 17
Attached scsi disk sds State: running
scsi3 Channel 00 Id 0 Lun: 18
Attached scsi disk sdt State: running
scsi3 Channel 00 Id 0 Lun: 19
Attached scsi disk sdu State: running
scsi3 Channel 00 Id 0 Lun: 2
Attached scsi disk sdd State: running
scsi3 Channel 00 Id 0 Lun: 20
Attached scsi disk sdv State: running
scsi3 Channel 00 Id 0 Lun: 21
Attached scsi disk sdw State: running
scsi3 Channel 00 Id 0 Lun: 22
Attached scsi disk sdx State: running
scsi3 Channel 00 Id 0 Lun: 23
Attached scsi disk sdy State: running
scsi3 Channel 00 Id 0 Lun: 24
Attached scsi disk sdz State: running
scsi3 Channel 00 Id 0 Lun: 25
Attached scsi disk sdaa State: running
scsi3 Channel 00 Id 0 Lun: 26
Attached scsi disk sdab State: running
scsi3 Channel 00 Id 0 Lun: 27
Attached scsi disk sdac State: running
scsi3 Channel 00 Id 0 Lun: 28
Attached scsi disk sdad State: running
scsi3 Channel 00 Id 0 Lun: 3
Attached scsi disk sde State: running
scsi3 Channel 00 Id 0 Lun: 4
Attached scsi disk sdf State: running
scsi3 Channel 00 Id 0 Lun: 5
Attached scsi disk sdg State: running
scsi3 Channel 00 Id 0 Lun: 6
Attached scsi disk sdh State: running
scsi3 Channel 00 Id 0 Lun: 7
Attached scsi disk sdi State: running
scsi3 Channel 00 Id 0 Lun: 8
Attached scsi disk sdj State: running
scsi3 Channel 00 Id 0 Lun: 9
Attached scsi disk sdk State: running
其他观察
出于某种原因，dm每当写入请求合并到请求队列中时，映射到“物理”LUN 的设备都会显示等待时间显著增加。但我的问题实际上是关于底层设备上的等待 - NetApp FAS 应该将所有写入请求放入其 NVRAM 并立即确认，即使是同步写入，因此我永远不会看到超过 5ms 的等待时间，只要网络链路没有饱和（事实并非如此）并且 NVRAM 没有背压（事实并非如此 - FAS 当前没有处理任何其他负载）。
对于读取操作，即使是随机读取，“等待”时间也相当短。以下是 10 秒 sysstat 数据的可视化，数据来自以下间隔：iozone正在运行随机读/写测试（单线程自动的启用 O_DSYNC、8K 块大小的测试运行）显示效果：
图的前半部分是随机读取，运行速度约为 2-4 kIOPS，延迟约为 3ms。在后半部分，工作负载切换到随机写入，await 上升到 >10ms，IOPS 下降到 ~100（负载受延迟限制且为单线程，因此 IOPS 与延迟成反比）
由于某种原因，在分析上述网络流量捕获时，Wireshark 的 SCSI“服务响应时间”统计功能无法识别大多数调用，write只发现 19 个请求并报告 3 毫秒的平均服务响应时间，而我预计大约有 500 个调用和类似于 34 毫秒等待的平均 SRT 值。
使用的 Linux 是 SuSE SLES 11 SP3，内核 3.0.101-0.47.55-default。
答案1
评论太长；
我不是 Linux 专家，但在 Windows 中我禁用TCP 大量发送卸载在 NIC 上，因为它会产生延迟。它发送的数据包较少，但较大，但对于关键 IO 不建议这样做。
官方解释；
TCP Large Send Offload 选项允许 AIX TCP 层构建长度最多为 64 KB 的 TCP 消息，并通过 IP 和以太网设备驱动程序在一次调用中将其发送到堆栈下方。然后，适配器将消息重新分段为多个 TCP 帧以进行传输。在线路上发送的 TCP 数据包要么是 1500 字节帧（最大传输单元 (MTU) 为 1500）或最多 9000 字节帧（MTU 为 9000）（巨型帧）。
答案2
我将根据进一步的信息编辑此答案。首先，我们需要确定 Netapp 是否也观察到了等待，还是只有主机观察到了等待。如果主机看到服务时间较长，但 NAS 声称服务时间较短，则可能是 NAS 端口和服务器的 SCSI 堆栈之间存在问题。
您运行的是哪个版本的 Data ONTAP？7 模式还是 CDOT？LUN OS 设置和 igroup OS 设置是什么？有了这些信息，我可以为您提供可在 Netapp 上使用的命令，以检查存储观察到的延迟。