高いI / Oタイムアウトを設定することの欠点は？

Question

パーティションがNetAppNASにマウントされているいくつかのLinuxVMに取り組んでいます。このNASは、定期的に非常に高いiowaitを経験し、VMディスクが読み取り専用モードに切り替わるか、クラッシュするか、破損します。

VMware KB では、緩和療法としてタイムアウト値を増やすことをお勧めします。

echo 180 > /sys/block/sda/device/timeout

非常に高いタイムアウト（1800以上）を設定すると、どのような悪影響がありますか？私の見方では、遅延した書き込みが蓄積されてI/O書き込みバッファがいっぱいになり、システムがクラッシュするリスクがあります。したがって、この解決策は問題よりも悪い可能性があります。

shodanshok · Accepted Answer

OSのダーティページキャッシュにキャッシュされているほとんどの書き込みは、すでに非同期で完了します。言い換えれば、それらはしばしばデバイスのタイムアウトとは何の関係もありません。

ただし、読み取りと同期書き込みには、基盤となるブロックデバイスからの即時の注意が必要です。これが、ファイルシステムが読み取り専用モードに切り替わる理由です（ジャーナルをディスクに書き込むことができません）。

I/O待機時間を増やしても悪影響はありませんが、特効薬ではありません。たとえば、基盤となるファイルシステムが読み取り/書き込みモードのままであっても、データベースは読み取り専用モードになる可能性があります。

sourcejedi · Answer

デフォルトのSCSIタイムアウトはすでに30秒であることに注意してください。それはすでにコンピュータ用語でかなり長い時間です:-P。

IO要求（非同期書き込みなど）は、/sys/class/block/$DEV/nr_requestsおよび/sys/class/block/$DEV/max_sectors_kbによって制限されます。古いシングルキューブロックレイヤーでは、合計メモリ使用量は2*nr_requests*max_sectors_kbと言われています。 2の因数は、読み取りと書き込みが別々にカウントされるためです。ハードウェアキュー内のリクエストも考慮する必要がありますが、たとえば、 cat /sys/class/block/sda/device/queue_depth。通常、ハードウェアキューの最大深度がnr_requestsの半分以下であることを確認する必要があります。

1）と書かれている IOリクエストに必要なスペースが多すぎると、メモリ不足エラーが発生します。 したがって、特定のシステムで上記の値を確認できます。通常、それらは問題ではありません。 nr_requestsのデフォルトは128です。max_sectors_kbのデフォルト値はカーネルのバージョンによって異なります。

新しいマルチキューブロックレイヤー（blk-mq）を使用する場合、読み取りと書き込みは別々にカウントされません。したがって、方程式の「2を掛ける」部分はなくなり、代わりにnr-requestsはデフォルトで256になります。 blk-mqでハードウェアキュー（または複数のキュー）がどのように扱われるかはわかりません。

リクエストキューがいっぱいになると、非同期書き込みが「ダーティリミット」に達するまでページキャッシュに蓄積される可能性があります。歴史的に、デフォルトのダーティ制限はRAMの20％として説明されていますが、正確な決定は最近では少し複雑になっています。

ダーティリミットに達したとき、あなたはただ待つ必要があります。 カーネルには、SCSIタイムアウト以外のハードタイムアウトはありません。 その意味で、VMware KBを含む、このトピックに関する一般的なドキュメントで十分です。 NAS :-P。NASのさまざまなヴィンテージは、さまざまな最悪の場合のタイミングを提供するように設計されています。

2）とはいえ、プロセスがディスクIOを120秒以上待機している場合、カーネルは「ハングしたタスク」の警告を出力します（おそらく、これが通常のデフォルトです。私のバージョンのFedoraLinuxでは、カーネルはCONFIG_DETECT_HUNG_TESTなしでビルドされているようです。Fedoraはここでは奇妙な異常値のようです）。

ハングしたタスクメッセージはクラッシュではなく、カーネルの「汚染された」フラグを設定しません。

10回ハングしたタスク警告（またはsys.kernel.hung_task_warningsに設定したもの）の後、カーネルはそれらの印刷を停止します。これについて考えると、私の意見では、SCSIタイムアウトを超えるように、sysctl sys.kernel.hung_task_timeout_secsも増やす必要があります。 480秒。

3）個々のアプリケーションには独自のタイムアウトがある場合があります。カーネルにIOエラー！ファイルシステムIOエラーは致命的と見なされるのではなく、アプリケーションのタイムアウトを確認する方がよいでしょう。ファイルシステム自体が再マウントされる可能性があります。 IOエラーの後、構成によっては読み取り専用。IOスワップデバイスまたはメモリマップファイルのエラーは、影響を受けるプロセスにSIGBUS信号を送信します。これは通常、プロセスを終了します。

4）systemdを使用すると、ウォッチドッグタイマーが設定されているサービスが強制的に再起動される可能性があります。 systemdの現在のバージョンでは、たとえば次のように表示されます。 systemctl show -p WatchdogUSec systemd-udevdを実行すると、3分のタイムアウトになります。これは4年前に増加しました別の理由で ;これがVMwareの推奨SCSIタイムアウトと一致するのは偶然の一致のようです:-)。これらの再起動により、警告ログノイズが発生する可能性があります。 systemdは、プロセスがスタックした場所を示すコアダンプを取得するという考えで、SIGABRTを使用してプロセスを強制終了します。ただし、udevやjournaldのようなものは、最近再開されて非常に満足しているはずです。

主な懸念事項は、ユーザースペースの再起動ウォッチドッグが短すぎることを構成していないことを確認することです。 RuntimeWatchdogSec= in /etc/systemd-system.conf。スワップを使用しない場合でも、カーネルの「直接再利用」に入るメモリ割り当てによって、systemdがディスクIOによってブロックされる可能性があります。