ソフトウェアRAID0のSSDは、有用なCPU作業スループットの最大化を支援または妨害しますか？
私の質問はタイトルにあります...ここにいくつかの背景があります：
[OSはLinuxです。]
[PDATE：このRAID0の内容は冗長です（SCMから同期されます）。データ損失のリスクが高まることを心配していません。]
[PDATE 2：実際には、ここで髪を分割している可能性があります。しかし、実際的な問題を解決しようとすることに加えて、私は理論の理解を改善/確認したいと思っています。]
非常に大規模なプロジェクトのソースコードをコンパイルするために使用する自動ビルドサーバーがあり、ビルド時間を最小限に抑えたいと考えています。ビルドの全期間（つまり、すべてのコアが100％でロードされている間）、マシンがCPUにバインドされたままである場合、可能な限り最高のビルド時間が発生すると思います。これはもちろん、次のような理想的な目標です。漸近的に近づきました。
ビルドの動作（主にmpstatの出力を監視）から、私の目標の最大の敵は％iowaitであることがわかります。無視できない％idleが表示されることがあり、カーネルのスケジューラーのわずかな障害や、ビルドを並列化するMakeの機能のわずかな非効率性を考慮します。しかし、これは一般的に私が心配するのに十分な大きさではありません。一方、％iowaitは非常に頻繁に大幅にサイズが大きくなり、CPU負荷が大幅に低下します。これは通常、一部のスレッドが大きなライブラリを（ソフトウェア制御[*]）RAID0にリンク（書き込み）しようとしているときに、他のスレッドがソースコードを読み取ろうとしているときに発生すると思います。
（出力書き込みをソースコードとは異なるボリュームとコントローラーに移動できるという事実は、今のところ無視してください。これは計画されています。）
SSDへの切り替えを検討しています。しかしその場合、ドライブのソフトウェアRAIDing [*]を放棄するのがおそらく最善だと思います。私の直感は次のとおりです。SSDのアクセス時間は非常に速く、転送時間は非常に速いため、4つのSSDの単純なLVMは、％iowaitsをほぼゼロに押しつぶし、コアは常にペグされ、最大のパフォーマンスを発揮します。有用な作業量。
...この場合、4つのRAID SSDのソフトウェア制御により、％sysが不必要に増加し、％userの残りが少なくなります。私のコアはまだ固定されていますが、実行される「有用な」作業は少なくなります。
この特定の目標に対して、ソフトウェア-RAID0のSSDに関する私の直感は正しいですか？
[*]ボーナス質問：マザーボードにはRAIDコントローラーがありますが、私の理解では、これは単なる「偽のRAID」であり、BIOSオプションROM内でボリューム管理機能を提供しますが、それ以外の場合はソフトウェアRAIDのみです。だから私はそれを使いません。しかし、真のハードウェアRAIDコントローラーはここでも役立ちますか？このマシンでコアを非常に簡単にペグできることは明らかです。私はそれを維持することはできません。 SSDはほとんどそのスタミナの問題を解決すると信じており、実際のハードウェアRAIDコントローラーでさえそれを改善できるかどうか疑問に思っています。
最新のハードウェア上のLinuxでのソフトウェアRAIDは問題ありません... SSDでも。それはあなたのCPUに大きな要求を課しません。本当に。
プレミアム Fusion-ioソリッドステートドライブ の場合、推奨される一般的な展開スキームは、ソフトウェアRAIDを使用することです。
私はこれについて全く心配しません。
以下も参照してください： Fusion-ioカードをRAIDする必要がありますか？
上記の@ewwhiteの回答を受け入れましたが、経験的データに基づいて、Webの他の場所で発見した、わずかに矛盾する回答について報告したいと思いました。
テストの結果は、RAID 0で（2）SSDを使用しているときに読み取りが16％増加し、書き込みパフォーマンスが2％低下することを示しました。読み取りによるパフォーマンスの向上は、ほとんどの目的でRAID 0を利用することを保証するのに十分ですが、読み取りよりも多くの書き込みを実行するアプリケーションを実行している場合は、データディスクをスタンドアロンで使用する代わりに、スタンドアロンで使用する方がメリットがあります。 RAID0オプション。
（私のRAIDは書き込みよりも読み取りを行っているので、@ ewwhiteの答えはまだ私のニーズに適しています。）