我的问题就在标题里...这里有一些背景信息：
[操作系统是Linux。]
[更新： 此 RAID0 的内容是冗余的（从 SCM 同步）。我并不担心数据丢失的风险增加。]
[更新2：实际上，我可能在这里吹毛求疵。但除了尝试解决实际问题之外，我还想提高/确认我对理论的理解。]
我有一个自动构建服务器，用于编译一个非常大的项目的源代码，我希望最大限度地缩短构建时间。我认为，当机器在整个构建过程中保持 CPU 受限时（即所有核心始终以 100% 的负载加载），构建时间将达到最佳。这当然是一个理想化的目标，只能渐近地实现。
我可以从构建行为（主要是观察 mpstat 的输出）中看出，实现目标的最大敌人是 %iowait。有时我会看到一个不可忽略的 %idle，我认为这是内核调度程序的轻微故障，和/或 Make 并行构建能力的轻微低效。但这通常不足以让我担心。另一方面，%iowait 经常会变得非常大……并且我的 CPU 负载急剧下降。我相信这通常发生在一些线程试图将大型库链接（写入）到（软件控制的[*]）RAID0 而其他线程试图读取源代码时。
（请暂时忽略我可以将输出写入移动到与源代码不同的卷和控制器的事实。这是计划好的。）
我正在考虑改用 SSD。但在这种情况下，我认为最好放弃对驱动器进行软件 RAIDing[*]。我的直觉是：SSD 的访问时间非常快，传输时间也非常快，以至于 4 个 SSD 的简单 LVM 会将我的 %iowaits 压缩到接近于零，然后我的核心将不断固定，做最大数量的有用工作。
... 在这种情况下，对 4 个 RAIDed SSD 的软件控制会不必要地增加我的 %sys，留给 %user 的空间会变小。我的核心仍然会受到限制，但完成的“有用”工作会减少。
对于这个特定目标，我对软件 RAID0 SSD 的直觉是否正确？
[*] 附加问题：主板上有一个 RAID 控制器，但我的理解是它只是“假 RAID”，在 BIOS 选项 ROM 中提供卷管理功能，但除此之外只是软件 RAID。所以我不使用它。但真正的硬件 RAID 控制器在这里会有帮助吗？很明显，我可以很容易地在这台机器上固定我的核心；我只是无法维持它。我相信 SSD 基本上可以解决这个耐力问题，我发现自己想知道即使是真正的硬件 RAID 控制器是否也能改善这一点。
答案1
在现代硬件上，Linux 下的软件 RAID 很好……即使使用 SSD 也是如此。它不会对您的 CPU 提出巨大的要求。真的。
哎呀，有保费Fus-io 固态硬盘其中，推荐且常见的部署方案是采用软件RAID。
我根本不担心这个。
答案2
尽管我已经接受了上述@ewwhite 的回答，但我还是想回过头来报告一个我刚刚在网上其他地方发现的略有冲突的答案，该答案基于经验数据：
我们的测试结果显示，在 RAID 0 中使用 (2) 个 SSD 时，读取速度增加了 16%，而写入性能下降了 2%。读取性能的提升足以保证在大多数情况下使用 RAID 0，但如果您运行的应用程序执行的写入次数多于读取次数，那么使用独立数据磁盘可能比使用 RAID 0 选项更有优势。
（我的 RAID 读取的多于写入，因此@ewwhite 的回答仍然适合我的需要。）