-
skb_over_panic
Posted on 2月 10th, 2009 はおりん No commentsOSが死ぬとき
昔よく、「Windowsはすぐにブルースクリーンで死ぬから嫌いだ」と言われていたことがあった。当時、僕の周囲にはLinux信者が多く、そしてその信者の多くがWindows嫌いだったのだ。というより、WindowsではなくLinuxを使っている自分に酔っていたと言うか・・・
そういう「信者」にありがちな行為が上記の比較。たしかに、Windowsが青い血を吐いて死んでしまったら、その原因をトレースするのはかなり困難だ。しかし、Linuxが死なないかというと、実はそんなことはない。そして、いざOSが死ぬと、その原因究明はWindowsでもLinuxでも、同じように困難なのだ。カーネルパニック
Windowsのブルースクリーンと同等の現象が、Linuxで言うところのカーネルパニックである。カーネル内部でのメモリ読み書きエラーやIOエラーなどで落ちるので、これが出た瞬間にOSはハングアップする。そして原因の究明はほとんど不可能と言っていいくらい困難である。
あえて原因を追究したいならば、ブルースクリーンでもカーネルパニックでも、最近のOSではメモリダンプというものをHDDに吐き出している。これはカーネルに関わる部分のメモリ領域をまるごとHDDに書き出したもので、この中を解析すればどの関数で落ちたか、引数はどんなだったか、などが追えるということだ。
しかし、このメモリダンプを追うには、デバッガやトレーサ、ほかにもいろいろ必要であり、これはWindowsでもLinuxでも変わらない。OSの標準機能としてブルースクリーン/カーネルパニックの原因究明を補助してくれるようなことは無いのである。skb_over_panic
そして、ことさらに厄介なのが、組み込み系OSのパニックである。これはもうほとんど追跡不可能と言って良い。ほぼリアルタイムにデバッグをしていないと、原因は究明できないだろう。
そして僕はVMWare ESXiで、いやぁ~なパニックに出会ってしまった。それが上記の、skb_over_panicである。VMルータ
Core i7サーバにはいくつかのVMが入っている。
・動画変換用Windowsサーバ
・開発用
・ROのエミュ鯖
・ルータ/VPN
・Apache/SVN/DNS/PostgreSQL
全部で5つのVMだ。今回、ルータを市販のものからVMを利用するよう、デスクトップマシンの設定を変更した。そして高負荷をかけ続けたところ、上記のパニックを起こしてVMのハイパーバイザごと死んでしまった。ルータ以外のVMまで、すべて死んでしまったのである。しかし、どうも原因がわからない。高負荷をかけるとすぐに落ちるわけでもない。ApacheBenchをかけても落ちない。同時接続数とかそういう問題じゃないっぽい。わからないので、設定を元に戻し、そのまま放置してしまった。ジャンボフレーム
昨日、ふと思い立ってVM内の仮想NICのMTUを調整してみようと思った。が、ジャンボフレームに設定できない。MTUが1500より大きい値にならない。
もしかして、ジャンボフレームである必要って無いのかな?と思って、Pingで8000バイトのフレームを送ってみた。
落ちた・・・
なっ!なんだと?!どうやら1500バイトより大きいフレームを送りつけると、うちのESXiはskb_over_panicで落ちてしまうようだ。skb_over_panicとは、どうやらネットワーク用のバッファがオーバーした、というような感じらしい。結局解決方法はわからず・・・ついでにルータが死んだ
上記パニックを起こした際に、ルータの仮想HDDのデータが破損してしまった。幸い、他のVMでは異常なかったものの、ルータは完全にシステムファイルが飛んでしまい、再インストールすることになってしまった。その関係上、昨日の夜から夜中まで、サーバが停止してしまった。Apacheサーバでなかっただけ、不幸中の幸いである。
バックアップ体制を整えなければ・・・解決方法募集します。
この、skb_over_panicについて、解決方法をご存知の方はぜひお知らせください。
ハードウェア Core i7, Linux, VMware, 失敗7 Responses to “skb_over_panic”
-
初めまして、DAIです。
JunkersRingのDatnioさんの所から飛んで来ました。確かskb_over_panicのエラーって、ソケットのバッファが溢れた時に吐くやつだったと思います。
調整は可能ですが、kernelの再コンパイルが必要です。それにしても、Core i7いいですねぇ。
うちは、PhenomX4 9350e+Windows Server 2008の環境でHyper-Vにしちゃってますが、OpenSolaris+VMwareでもう一台組みたくなってきました。 -
そうなんです、「ソケットのバッファが溢れた時」までは分かったんです!そうですかー、カーネルの再コンパイルですかー・・・
VMWareのカーネルって、再コンパイルとか調整とか出来るんだろうか・・・
Hyper-VってたしかWindowsServerの仮想化でしたっけ?なんか、Windowsも知らない間に進化しちゃって・・・w
仮想化お詳しいですか?いろいろ教えてくださーいw -
>skb_over_panic
確か、この辺りにあった気がします。。。↓
net/core/skbuff.c以前、どっかの海外サイトで見たことはあるのですが、具体的にどうするかは調べてみないとわかんないです。
ちなみに、Hyper-Vはそうです!
Server2008の仮想化ソフトです。
稼動OSは、こんな感じです↓
・NetBSD 4.01
・OpenSolaris 2008.11
・RedhatEnterpriseLinux ES5 Update3
・Nexenta 2.0Beta
・Jなんとか社のコアルータのシミュレータ用FreeBSDその上でリバースプロキシとして実稼動のサーバは、
・CobaltRaQ550@Strongbolt 1.04(2台)
みたいな感じです。一応本業はネットワーク屋でございますが(笑
持っている知識であれば展開しますです。詳しいかどうかは微妙かもしれませんが、これを機に交流したいですー@
-
たびたびすいません(笑
軽く情報を漁ってみたのですが、Kernel2.6系でのバグ?扱いされているケースが多いようですね。
また、環境によってはIPv6を無効化することにより、改善したとの事例もありました。
-
>これを機に交流したいですー@
是非!wあー、ほー、バグ扱いですかー、やっぱりバグなのかなー・・・
IPv6を無効化・・・さっそく試してみますっ! -
だめでしたーー
VMWare ESXiには、IPv6が云々という設定は見当たらず・・・
いろいろバッファ関連の設定もいじってみるも、症状変わらず。
うーん・・・ -
あらら。。。
暇があったら、ESXiをちょっと見てみます!
ESXの方なら、とある会社を個人で手伝った際に弄ったことはあるのですが・・・
あと、事後報告ですいませんが、うちのブログでリンクを張らせて頂きました!
コメントを書く
-