「UNIXサーバはリブートすべきでない説」記事へのコメント

メモリダンプ取って再起動

[Anonymous Coward]

サービスの復旧を優先するか、問題の解決を優先するかの優先度によっても、どちらがいいかという判断は分かれるのではないか？

システムの動態解析というのは、開発時のテストの時ぐらいしかやらないのでは？
どちらかというと、メモリダンプを取って、再起動というのが多いかな。死体(メモリダンプイメージ)の解析には時間をかけられるが、システムがまともに動かない時間というのは、外圧が大きすぎて、時間をかけられない為です。下手に動作を継続して、データを破壊でもされたら、余計に、復旧に時間がかかりますからね。

最近は、テラバイトクラスのメモリを積んでいて、メモリダンプを取るだけで８時間以上かかる大型システムも増えていますので、問題の種類にもよるが、再起動なんかする前に、予備系にさっさと切り替えてしまう方が多いのではないかな？

Re:メモリダンプ取って再起動

[cm (41778)]

>メモリダンプを取って、再起動というのが多いかな。

メモリダンプを取らないという判断もあった。
三回ほどOSがフリーズしたたびに、ベンダーの言う通り、ちょっと時間かけてメモリダンプをとって提出したが「原因不明」と三回とも回答があったので「御社システムにおいて、メモリダンプは意味がないと思われる、メモリダンプ取得によって原因究明という実績がない。実績を出せる様になってから要求せよ」と伝えたら、「次回からはログ提出提出のみを依頼いたします」だとさ。
そして、メモリ容量がでかくなって、メモリダンプ取っていたら契約上許される時間でのサービス復旧は無理。
なので、方式設計レベルで「問題発生時は、メモリダンプなどの取得をせず、再起動後に取得できるログファイルなどから解明を行う。解明できる確率は低いが、これまでの実績からメモリダンプにより解明できたケースが皆無であることも考慮した」とか書かれていたりする。

>再起動なんかする前に、予備系にさっさと切り替えてしまう方が多いのではないかな？

予備系に切り替えは、デザスタリリカバリとかで、ダウンタイムがそれなりに大きくなると予想されていたりとかね。
クラスタの切り替え、だめなら再度の全再起動、それでだめなら災害対策用センターにあるシステムに火をいれつつ..とかね。

Re:

[Anonymous Coward]

ダンプは状態がわかるだけでその状態に至った過程が解らない場合がありますしね。
でもログだけ採取って「ログだけじゃ原因わかりませんでした」って逃げるためのような…。
本気でどうにかしようとすればログ強化だと思いますが(性能低下の弊害もあるけど)、OSの場合手が出ないか。

ディザスタリカバリはどっちかっていうとデータバックアップで、サービスに対するフェイルセーフとしては
使われないと思います。アクティブ-アクティブならまあダウンタイム減らせるでしょうがその場合
切り替えではないですよね。

Re:メモリダンプ取って再起動

[cm (41778)]

>「ログだけじゃ原因わかりませんでした」って逃げるためのような…。

で、以前はダンプがあればということで、三回ほどだしたのだが、原因不明だった、なので、今ならわかるなら、今、あの三年前の事故の報告をだしてくれないか？
出せない？じゃ、どうしたら原因究明できるんだい？ベンダーとして責任をとってね..と追いつめたお方がいますね。

で、ごめんなさいということで、筐体の無料提供、ついでにOSもDBMSもあげて(実はリプレース..ww)のコスト削減、しかも以後は再発なしとかあったりする。

>アクティブ-アクティブならまあダウンタイム減らせるでしょうがその場合

HWの問題だとわかる場合には、有効なんだけど、ソフトウェアというかアプリやDBMSがタコだと、アクティブ-アクティブだと共倒れのケースが多かったと思う。
サービスのOS間移動と戻しで戻ったケースもあるけどね。