☰

提高 Linux 上 SAS 多路径至 JBOD 的性能

tag-icon • tag-icon linux storage sun sas multipath
提高 Linux 上 SAS 多路径至 JBOD 的性能

我正在尝试使用 Linux 优化某些 Sun 硬件上的存储设置。任何想法都将不胜感激。

我们有以下硬件：

  • 太阳之刃 X6270
  • 2* LSISAS1068E SAS 控制器
  • 2* Sun J4400 JBOD，配备 1 TB 磁盘（每个 JBOD 24 个磁盘）
  • Fedora Core 12
  • FC13 发布的 2.6.33 内核（也尝试使用 FC12 的最新 2.6.31 内核，结果相同）

这是 SAS 硬件的数据表：

http://www.sun.com/storage/storage_networking/hba/sas/PCIe.pdf

它使用 PCI Express 1.0a，8x 通道。每通道带宽为 250 MB/秒，我们应该能够实现每个 SAS 控制器 2000 MB/秒。

每个控制器每个端口可达到 3 Gb/秒，并具有两个 4 端口 PHY。我们将两个 PHY 从控制器连接到 JBOD。因此，在 JBOD 和控制器之间，我们有 2 个 PHY * 4 个 SAS 端口 * 3 Gb/秒 = 24 Gb/秒的带宽，这超过了 PCI Express 带宽。

启用写入缓存并进行大量写入时，每个磁盘可以维持约 80 MB/秒（接近磁盘的起始位置）。使用 24 个磁盘，这意味着我们应该能够为每个 JBOD 实现 1920 MB/秒。

多路径 {
  rr_min_io 100
  用户 ID 0
  path_grouping_policy 多总线
  故障恢复手册
  path_selector“循环0”
  rr_weight 优先级
  别名 somealias
  no_path_retry 队列
  模式 0644
  组 ID 0
  wwid 某某
}

我尝试将 rr_min_io 的值设为 50、100、1000，但似乎没有太大区别。

除了改变 rr_min_io 之外，我还尝试在启动 dd 之间添加一些延迟，以防止它们同时写入同一个 PHY，但这没有任何区别，所以我认为 I/O 已经得到适当分散。

根据 /proc/interrupts，SAS 控制器使用“IR-IO-APIC-fasteoi”中断方案。出于某种原因，机器中只有核心 #0 处理这些中断。我可以通过为每个 SAS 控制器分配一个单独的核心来处理中断来稍微提高性能：

echo 2 > /proc/irq/24/smp_affinity
echo 4 > /proc/irq/26/smp_affinity

使用 dd 写入磁盘会生成“函数调用中断”（不知道这些是什么），这些中断由核心＃4 处理，因此我也将其他进程从该核心中移除。

我运行 48 个 dd（每个磁盘一个），将它们分配给不处理中断的核心，如下所示：

任务集-c somecore dd if=/dev/zero of=/dev/mapper/mpathx oflag=direct bs=128M

oflag=direct 可防止任何类型的缓冲区缓存参与。

我的所有核心似乎都没有达到极限。处理中断的核心大多处于空闲状态，而所有其他核心都在等待 I/O，这一点是意料之中的。

Cpu0：0.0％us、1.0％sy、0.0％ni、91.2％id、7.5％wa、0.0％hi、0.2％si、0.0％st
CPU1：0.0％us、0.8％sy、0.0％ni、93.0％id、0.2％wa、0.0％hi、6.0％si、0.0％st
CPU2：0.0％us、0.6％sy、0.0％ni、94.4％id、0.1％wa、0.0％hi、4.8％si、0.0％st
CPU3：0.0％us、7.5％sy、0.0％ni、36.3％id、56.1％wa、0.0％hi、0.0％si、0.0％st
CPU4：0.0％us、1.3％sy、0.0％ni、85.7％id、4.9％wa、0.0％hi、8.1％si、0.0％st
CPU5：0.1％us，5.5％sy，0.0％ni，36.2％id，58.3％wa，0.0％hi，0.0％si，0.0％st
Cpu6：0.0％us、5.0％sy、0.0％ni、36.3％id、58.7％wa、0.0％hi、0.0％si、0.0％st
CPU7：0.0％us、5.1％sy、0.0％ni、36.3％id、58.5％wa、0.0％hi、0.0％si、0.0％st
CPU8：0.1％us，8.3％sy，0.0％ni，27.2％id，64.4％wa，0.0％hi，0.0％si，0.0％st
Cpu9：0.1％us，7.9％sy，0.0％ni，36.2％id，55.8％wa，0.0％hi，0.0％si，0.0％st
Cpu10：0.0％us，7.8％sy，0.0％ni，36.2％id，56.0％wa，0.0％hi，0.0％si，0.0％st
Cpu11：0.0％us，7.3％sy，0.0％ni，36.3％id，56.4％wa，0.0％hi，0.0％si，0.0％st
Cpu12：0.0％us，5.6％sy，0.0％ni，33.1％id，61.2％wa，0.0％hi，0.0％si，0.0％st
Cpu13：0.1％us，5.3％sy，0.0％ni，36.1％id，58.5％wa，0.0％hi，0.0％si，0.0％st
Cpu14：0.0％us，4.9％sy，0.0％ni，36.4％id，58.7％wa，0.0％hi，0.0％si，0.0％st
Cpu15：0.1％us，5.4％sy，0.0％ni，36.5％id，58.1％wa，0.0％hi，0.0％si，0.0％st

考虑到所有这些，运行“dstat 10”报告的吞吐量在 2200-2300 MB/秒范围内。

根据上述数学知识，我预计范围在 2*1920 ~= 3600+ MB/秒之间。

有人知道我丢失的带宽去哪儿了？

谢谢！

答案1

好问题，准备充分：）

我自己就是一个速度和馈送专家，说实话我认为你说的很对。我原本以为你的吞吐量会比现在低，但我认为你那里有小的、预期的低效率。例如，PCIe 总线很难一直达到 100%，最好假设总体速率低至 90%。考虑到这会导致抖动，这也意味着 PHY 不会一直 100%“馈送”，所以你也会损失一点，缓存、磁盘、非聚合中断、IO 调度等也是如此。基本上是小效率乘以小效率乘以……等等，最终会超过预期的 5-10% 的低效率。我曾见过 HP DL 服务器使用 W2K3 与 MSA SAS 盒通信，然后通过多个 NIC 进行 NLB 的情况 - 令人沮丧，但我想这是可以理解的。无论如何，这是我个人的看法，抱歉，这不是太积极。

相关内容