なぜパリティチェックはホームサーバーのすべてのアプリを遅くするのか？

パリティチェックはほとんどまたはすべてのメンバーディスクを連続的に読み取るため、ホームサーバーのアプリケーションを遅くします。これはデータベース、メディアストリーム、コンテナ、ファイル共有と遅延、キュー深度、キャッシュ、帯域幅を争うためです。

CPUはほとんどアイドル状態に見えても、リクエストはストレージで待機していることがあります。実用的な対策は、チェックが正常であることを確認し、需要の少ない時間帯にスケジュールし、I/O優先度や速度を下げ、プラットフォームが許す場合は遅延に敏感なワークロードを分離することです。

チェックはすべてのディスクを共有リソースに変える

パリティ操作はアレイ全体のストライプをスキャンし、前景のアプリケーションが無関係な読み書きを行う間にパリティを計算または比較することがあります。総スループットが高く保たれていても、長時間の連続メンテナンストラフィックは小さなランダム要求の待ち時間を増加させる可能性があります。

そのため、メディアストリームがバッファリングしたり、データベースクエリが一時停止したり、コンテナのUIが遅く感じられたりすることがあります。共通のボトルネックは共有ストレージパスであり、9つの独立したアプリケーションの障害ではありません。

帯域幅が満杯に見える前に遅延が上昇する

ホームサーバーのダッシュボードはしばしば毎秒メガバイト数を表示しますが、キューイング遅延は隠しています。ディスクは余裕のある連続帯域幅を持っていても、小さな同期書き込みは長いメンテナンス要求の後ろで待機することがあります。アプリケーションの応答時間はスループットグラフが劇的な最大値に達する前に悪化します。

実際のmdadmの再同期によるシステム応答不能は、RAIDの速度制限を下げることで改善され、メンテナンスを迅速に終わらせることとインタラクティブな応答性を保つことのトレードオフを示しています。

パリティ作業は読み取りと書き込みの調整を追加する

チェックのみの操作は主に読み取りが中心ですが、修復や同期では修正されたパリティを書き込むこともあります。RAID5やRAID6の前景での小さな書き込みはすでにストライプ全体の調整が必要なため、メンテナンストラフィックが遅延を増幅させることがあります。

RAIDパフォーマンステストでは、パリティのリード・モディファイ・ライトが小さな書き込みに対して複数のディスクを動作させる仕組みを説明しています。パリティチェック中は、同じメンバーが連続スキャンも担当しています。

キャッシュとダーティライトのバーストが一時停止を不均一にすることがあります

アプリケーションはしばらく正常に見えることがありますが、メモリが書き込みを吸収しているためです。ダーティデータがフラッシュされると、前景のI/Oがバーストで到着し、チェックと競合します。これにより一定の遅延ではなく周期的なフリーズが発生します。

ダーティページフラッシュの分析は、プロセス優先度だけではストレージレイテンシを解決できない理由を示します。デバイスキューの深さ、I/O待ち、ダーティメモリ、プロセスごとのレイテンシを一緒に観察してください。

チェック中の書き込みは通常許可されます

ほとんどのアクティブなアレイは、パリティチェックやスクラブ実行中でも通常の読み書きを許可します。実装は変更を調整してメンテナンスを継続しますが、両方のタスクは互いに遅くし、完了予測は変動します。

スクラブ中の書き込みに関する議論は実用的な境界を示しています：通常のアクセスはメンテナンス操作を遅くするだけで無効化しません。ただし、エラーや切断は通常の競合ではありません。

調整前にボトルネックを測定する

同じアプリケーションで通常の期間とチェックなしを比較します。1つの遅いディスクが全体のパリティ操作を制限し、予想以上に前景のレイテンシを悪化させることがあります。

データとアプリの両方を保護するメンテナンスポリシーを選択する

バックアップ、メディアスキャン、ダウンロード、写真のインデックス作成、仮想マシンが静かなときにチェックをスケジュールしてください。プロセスを突然停止するのではなく、プラットフォームがサポートする再構築やスクラブの優先度を使用してください。確実に完了する遅いチェックは、繰り返し中止するよりも優れています。

常時稼働サービスの場合、レイテンシ目標を設定し、メンテナンス速度をその目標以下に調整してください。データベース、コンテナメタデータ、アプリケーションキャッシュが配列の定期的な全スキャン負荷に耐えられない場合は、別のストレージに配置することを検討してください。

遅延が実際には障害の信号である場合

健全なパリティチェックは重いが安定したI/Oを生成します。速度が同じ領域付近で急落したり、I/Oエラーが増加したり、ディスクが繰り返しリセットされたり、温度が通常範囲を超えたり、1つのメンバーが極端に長いサービス時間を示す場合は調査してください。

症状が消えるまで単に速度を下げないでください。限界に近いディスクは、弱いセクターの再試行に長時間を費やし、通常のメンテナンス競合のように見えることがあります。

どのアプリが遅延を増幅しているか確認する

パリティチェックは共有配列に影響しますが、1つの書き込み負荷の高いサービスが影響を不均衡にすることがあります。プロセスごとのI/Oを比較し、オプションのインデクサー、ダウンロードクライアント、サムネイル生成、バックアップ圧縮ジョブを一時停止してからチェック速度を下げすぎないようにしてください。

このテストはメンテナンス時間を効率的に保ちながらインタラクティブなサービスを保護します。また、繰り返される問題がパリティチェック自体によるものか、2つのスケジュールされたストレージ集約タスクの衝突によるものかを明らかにします。

よくある質問

ユーザーからの苦情があったらパリティチェックを停止すべきですか？

サポートされている制御を使って一時停止やスロットル制御を優先し、その後再スケジュールしてください。状態を保存し、その中断が安全であることを確認してからのみ停止してください。

RAMを増やせば遅延を防げますか？

より多くのキャッシュは一部の読み書きをスムーズにしますが、同じディスクへの競合をなくすことはできません。また、書き込みをより大きなフラッシュバーストに先送りすることもあります。

より高速なCPUはパリティチェックを目立たなくしますか？

通常、ディスクがボトルネックの場合はそうではありません。パリティ計算はCPUを使用しますが、ホームサーバーの遅延は一般的にデバイスのレイテンシとキューの競合によって支配されます。

実用的なバランス

パリティチェックは配列全体を検査して整合性を保護するため、ある程度の競合は予想されます。スケジュールを調整し、スロットル制御を行い、レイテンシを測定し、すべての遅延を正常とみなすのではなく、エラーの増加を調査してください。