第8回「カーネルパラメーターチューニングノススメ」


今回は、システムがデッドロックしたり無応答状態に陥ったりしているかもしれない状況を警告する watchdog 系パラメーターについて紹介します。

死活監視ソフトウェアの設定にもよりますが、例えば Pacemaker では、 2 秒間隔で /dev/watchdog への書き込みを行いながら、10秒間(実際には余裕を見て11秒間)書き込みが行われなかった場合に、 /dev/watchdog 発動による再起動が行われる設定になっていることが多いようです。

近年では搭載メモリーが増えてきたことにより、メモリー回収処理が発生した場合の遅延時間も長くなってきるのではないかと思われます。また、仮想化環境では十分な CPU 時間が割り当てられなかったことで処理が遅延し、 /dev/watchdog 発動による再起動が発生しやすくなっているようにも思われます。もしかすると、 10 秒という /dev/watchdog のタイムアウト時間では短すぎるのかもしれません。

でも、なぜ「推測」なのかというと、予期せぬ再起動や系切り替えが発生したという問合せが多くなってきているのですが、 /var/log/messages などには何も警告メッセージが記録されていないために、本当に /dev/watchdog が発動したのかどうかを確認できないでいるからです。

もちろん、 /dev/watchdog 発動時のメッセージを確認するだけなら、シリアルコンソールや netconsole の設定をしておけば大丈夫です。でも、なぜ /dev/watchdog が発動したのかを知るためには、どのような問題が発生していたのかを知る必要があります。何も警告メッセージが出力されないと、手がかりさえつかめません。

なので、 Linux カーネルが備えている watchdog 系パラメーターのタイムアウト時間を短く設定することで、何らかの警告メッセージを出力させることを狙います。

ここでは、特定のプロセスが「 CPU 時間を占有し続けた場合」に出力される softlockup 特定のプロセスが「割り込み(による中断が)不可能なスリープ状態にあり続けた場合」に出力される hung check timer のタイムアウト時間を変更してみます。これらのタイムアウト時間を変更しても、タイムアウトによる警告メッセージの出力頻度が変化する以外にはシステムへの影響は無いはずですので、事前に検討しておいていただきたいです。

まず、 soft lockup のタイムアウト時間は /proc/sys/kernel/watchdog_thresh で指定でき、 RHEL 5 や RHEL 6 のデフォルト設定では 60 秒となっています。10 秒程度の /dev/watchdog タイムアウトが発生する前に検知するとなると、soft lockup のタイムアウト時間は 5 秒程度にする必要があるかもしれません。

次に、 hung check timer のタイムアウト時間および警告メッセージの出力回数は/proc/sys/kernel/hung_task_timeout_secs と /proc/sys/kernel/hung_task_warnings で指定でき、デフォルト設定ではそれぞれ 120 秒および 10 回となっています。/dev/watchdog タイムアウト前に検知するためには、 5 秒程度に設定する必要があるかもしれません。

また、 /dev/watchdog 以外のケース、例えば、 Serial ATA ディスクへのアクセスが Native Command Queuing 機能による遅延が発生しているかどうかを検知するには、タイムアウト時間だけでなく、出力回数も変更しておくのが良いと考えます。実際、システムの動作が遅延する事象が発生したけれども、最初の 10 回までしか警告メッセージが出力されていなかったために、遅延事象がいつ頃発症して解消したのかを確認できないというケースが見受けられます。遅延事象が始まってから解消されるまでの時間の目安として使うことができるようにするためには、 3 秒程度で1000000 回まで出力するような設定が有効かもしれません。

もっとも、これらの数値は私の経験則に基づく「予想」に過ぎませんし、いかなる状況に対しても警告メッセージを出力できるようになる訳でもありません。

もっと詳細なプロファイリングが必要な場合には、そのための機能を使うことになりますが、全ての動作を漏れなく記録しようとする方法だと CPU やディスクへの負荷が大きくなってしまいます。今回紹介したタイムアウトパラメーターのチューニングは、いつ事象が発生するかを予測できない状況において、負荷を増やさずに何らかのヒントを得ようとすることを目的としていることをご了承ください。

(半田哲夫)

コーヒーブレーク「急がば回れ」

今回は、前回の予告に従い「サポートセンターに注文をつけることなく、回答を急がせる、あるいは希望する時間に返事をもらう方法」について、極意を伝授したいと思います。と書きましたが、実は特にありません。正確に言えば、これまでの記事で説明しており、新たに追加するものはありません。

できれば、ここで過去の記事を読み直していただきたいのですが、答えを言うと、

  • ありのままに、正直に伝える、その上で
  • サポートセンターの判断に委ねる

ということが、実は求める結果を早く得る近道なのです。

「ありのままに伝える」のは、起こっている問題や不具合の内容、あるいは依頼の内容だけではなく、「顧客に報告を求められている」ことも含めても良いのです。ただ、サポートセンターに「午後 4 時までに結果を報告してください」のように強制したり、確約をもらおうとしたりしないのがポイントです。「希望のみを伝える」形なので、調整とはならないわけです。

「ありのままに伝えた後で、約束をして欲しい」気持ちは、個人的にはよくわかります。 約束をとりつけたいと思う気持ちはどこからくるか考えると、それは安心を得たいからであり、誰かに報告したいから、ではないかと思います。サポートセンターに対応を依頼したことを上司や関係者に報告するとして、「で何時に回答してもらえるんだ?」と聞かれたとき、「いや、それはわかりません」とは言いにくいでしょう。

こうしたやりとりが生じている状況について、救急センターに患者が運ばれてきたときに通じる部分があると思います。困っていることはわかっています。もちろん助けてあげたいし、助けてあげることが受け入れ側の仕事であり唯一の目的です。私は救急センターのお世話になった経験はありませんが、「助かりますか?」「家族に連絡するので何時までに様子を教えてください」と頼まれても、そうした要望は答えられないのではないかと思います。事態が重要であるために、不用意な約束や返事はできませんし、何より患者の症状を確認し、助けることに専念したいと思うはずです。

どうしても約束をして欲しいと思い、交渉を続けたとします。その間、患者は待たされて治療が遅れます。受け入れる側にとっては、交渉の時間は自分達が対応するための時間を奪う形になるわけです。要望ではなく、希望を残せば、それはきっと対応スタッフに伝えられ、可能であれば対処してもらえるでしょう。「忘れられてしまわないか心配」ですか?それは救急センターなりサポートセンターを信じられるかということになります。信頼できるところに相談するのであれば、伝えて待つが最上です。

(原田季栄)



第8回「カーネルパラメーターチューニングノススメ」