SSDプールは空き容量が15％未満になるとなぜ速度が低下するのか？
SSDプールは、容量がいっぱいに近づくと、書き込み、データの再配置、メタデータ、スナップショットに使えるクリーンな作業領域がコントローラーやファイルシステムに少なくなるため、速度が低下することがあります。
15％という数値は普遍的な限界ではありませんが、多くのホームサーバーのワークロードにとって有用な警告しきい値です。スナップショット、シンプロビジョニング、ファイルシステムのメタデータ、削除済みだが開いたままのファイル、discardサポートの欠如などにより、SSDコントローラーやストレージソフトウェアが実際に再利用できる領域が減少すると、プールに論理的な空き容量が残っている場合でも問題が起こります。1つのダッシュボードの割合だけに頼らず、実効的な書き込み余力と書き込みレイテンシを診断してください。
15％に達した空き容量の数値を確認する
SSDの物理容量、プール容量、ファイルシステムの空き容量、シンプロビジョニングによる割り当て量、スナップショットの使用量、クォータ、予約ブロック、そして速度低下を感じるアプリケーションボリュームを比較してください。これらはそれぞれ異なる問いに答える数値です。
GNU Coreutilsのファイルシステムの利用可能容量は、マウントされたファイルシステムの使用状況に基づいて報告されます。そのため、書き込みに影響するプール、スナップショット、シンボリューム、コントローラーレベルの予約領域がすべて反映されるとは限りません。
1つのデータセットまたはシンボリュームだけがほぼ満杯なら、すべてのSSDが遅いと考えるのではなく、そのレイヤーを修復してください。プール全体の未割り当て容量が少ない場合は、コントローラーの作業領域、discard、スナップショットの確認に進みます。
NANDへの書き込みにクリーンな作業領域が必要な理由を理解する
プールがしきい値を超える前後で、持続的な書き込みと小さなランダム書き込みのレイテンシを測定してください。読み取り速度が許容範囲に留まっていても、書き込みが一時停止したり、不安定になったりすることがあります。
Crucialは、SSDのオーバープロビジョニングを、ガベージコレクション、ウェアレベリング、交換用ブロックに使用される予約容量と説明しています。これにより、書き込み可能な余力が少ないほど、新しい書き込みの際にバックグラウンドでの再配置が増える理由が分かります。
速度低下のすべてがフラッシュメモリの寿命消耗を意味すると考えないでください。正常なSSDでも、受け取った書き込みごとにより多くの有効データを消去、移動、書き直す必要がある場合、一時的に遅くなることがあります。
discardまたはTRIMがSSDまで届いていることを確認する
削除されたファイルシステムのブロックが、継続的、定期的、またはまったくdiscardされていないか確認してください。ファイルシステムとSSDの間にある暗号化、RAID、シンプロビジョニング、HBA、仮想ディスク、エンクロージャーなど、すべてのレイヤーを確認します。
MicrosoftのOptimize-Volumeのretrim操作は、デバイスが再利用に備えられるよう、削除されたブロックの情報をストレージスタック経由で伝える必要があることを示しています。
ファイルシステムレイヤーでコマンドが成功しても、SSDがdiscardを受け取ったことの証明にはなりません。サポートされているtrim操作の前後でデバイスのカウンターや制御された書き込み動作を比較し、安全にdiscardを引き継げないレイヤーでは有効にしないでください。
スナップショット、ごみ箱、削除済みだが開いたままのファイルを確認する
スナップショット、クローン、保持フォルダー、ごみ箱、データベースログ、ディレクトリエントリが削除された後も開かれているファイルによって保持されている容量を測定してください。ユーザーがデータを削除したと考えていても、これらがブロックを割り当てたままにすることがあります。
OracleのZFSドキュメントでは、スナップショットが参照ブロックを保持すると説明されています。そのため、古いスナップショットがブロックを参照している間は、大きなライブファイルを削除してもストレージが解放されないことがあります。
保持ポリシーを超えた復元ポイントだけを削除し、どのブロックが参照されているかを確認してください。大きなスナップショットが必ずしも不要とは限らず、緊急時の削除によって最近の変更を復元する唯一の手段を失う可能性があります。
コントローラーのオーバープロビジョニングとファイルシステムの空き容量を分けて考える
各SSDに未パーティションの予約領域、メーカー定義の予備領域、またはホスト管理のオーバープロビジョニングがあるか確認してください。ファイルシステムの空き容量とコントローラーの予約領域は関連していますが、目的は異なります。
Kingstonは、ホストによるオーバープロビジョニングが容量を未割り当てのまま残すことで、SSDコントローラーにファイルシステムから見える空きブロック以外の追加の作業領域を提供すると説明しています。
検証済みのバックアップと、サポートされた縮小手順がない状態で、稼働中のプールを縮小しないでください。オーバープロビジョニングは、導入前に計画するか、管理された移行中に設定するのが最も安全です。
サポートされたtrimを実行し、回復を測定する
不要なデータとスナップショットを削除したら、負荷の低い時間帯にプラットフォームでサポートされているdiscard操作を実行してください。discardされたバイト数を記録し、SSDがバックグラウンドのクリーンアップを完了した後に書き込みレイテンシが変化するか確認します。
fstrimのマニュアルでは、discardはファイルシステムの未使用ブロックに適用され、同じ領域を繰り返しtrimしても追加の効果が得られない場合があると説明されています。
trimで0バイトと表示されても、必ずしも失敗とは限りません。ファイルシステムがすでにtrim済みであるか、中間レイヤーがdiscardをブロックしている可能性があります。マウントオプションを変更する前に、ストレージスタック自体の情報を確認してください。
余力を回復し、本当のボトルネックを確認する
一時データを移動し、ポリシーで承認されたスナップショットだけを期限切れにし、サポートされている場合はデータベースをコンパクト化して、意図的な空き容量の余裕を確保してください。その後、同じ書き込みワークロードを実行し、レイテンシ、キュー深度、CPU待機時間、SSD温度を測定します。
SSDキャッシュの警告サインに関するZimaSpaceの記事では、解消可能な空き容量不足の影響と、デバイス自体の故障を示す兆候の境界について説明しています。
検証済みの空き容量またはdiscardによる回復後に書き込みレイテンシが改善し、スナップショットとメタデータがポリシーの範囲内に収まり、選択した予備容量を上回る状態で同じワークロードが安定すれば、診断は完了です。十分な空き容量があるにもかかわらず性能が低い場合は、サーマルスロットリング、消耗度、コントローラーエラー、RAIDの動作、アプリケーションのI/Oを調査してください。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
