解決策 1:
RAID0 は使用しないでください。いずれかのドライブに障害が発生すると、アレイが停止します。 RAID6、RAID10、またはアレイなしの 1 台のドライブでも、可用性が向上します。
f2fs は、最新のソリッド ステート デバイスに対応するように設計されており、Linux の md は非常に高速に動作します。
ただし、配列に対して f2fs のような一般的なステートメントを作成することは不可能です。データがない方がよいでしょう。 I/O パターンが自分のシステムと同様のシステムでベンチマークされている場合、自分のワークロードが何であるか、およびどのような制限要因が存在するかを考慮する必要があります。
容量分析を行います。 1 秒あたりのデータベース クエリや、読み書きされるファイルの数などを見積もります。 iostat -xz 1 などのツールで IOPS を測定する . r/s の場合 そして w/s 数値がデバイスの定格容量に近づくと、より高速なディスクが必要になる場合があります。磁気回転あたり約 100 IOPS、ほとんどの SSD で少なくとも数千 IOPS を期待します。また、ディスクが SATA または NVMe として接続されているかどうかによっても異なります。
システム上のすべてのリソースのパフォーマンスを評価します。 CPU やメモリに制約がある場合、高速ストレージは限定的な助けとなります。メモリは、キャッシュとして特に役立ちます。スワップ ファイルはストレージ システムのパフォーマンスを低下させますが、DRAM ほど高速ではないため、過度のページアウトは好ましくありません。
システムのパフォーマンスを理解したら、ストレージ システムへの変更の評価を開始できます。
解決策 2:
従来の HDD で F2FS を使用するのは得策ではありません。ランダム書き込みのパフォーマンスはおそらく EXT4 や XFS よりも高くなりますが、古くなったファイルシステムでのシーケンシャル読み取り速度は非常に残念です。
電力損失から保護されたライト バック キャッシュ (読み取り:真の RAID コントローラ) を使用せずにランダム書き込みのパフォーマンスを向上させるには、アプリケーションを しない ように構成する必要があります。 fsync() を発行しますが、これはします 予定外のシャットダウンでデータが失われる可能性が大幅に高まります。 しない システム レベルでバリアを無効にします (つまり、カーネルにキャッシュを介して書き込みを行うように指示することにより)。これにより、電源が失われた場合にファイルシステム全体が破壊される可能性があります。
また、ZFS の使用を検討することもできます (ストライピングを MDRAID 層ではなく、ZFS 自体に残すことが望ましいです)。CoW の性質により、ランダム書き込みは他のファイルシステムよりも大幅に高速であり、高度なキャッシュは順次読み取りの問題を回避します。 sync=disabled もサポートしています :予期しないシャットダウンが発生した場合に最大 5 秒のデータ損失ウィンドウを許容できる場合は、アプリケーションまたはファイル システムの一貫性に影響を与えることなく、大量のランダム書き込み IOP を提供できます。
最後に、EXT4 を使用している場合は、data=journal で簡単なテストを行うことができます。 :これによりシーケンシャル書き込みのパフォーマンスが低下しますが、ランダム書き込みはデフォルトのジャーナル モードよりも多少速くなります。