アカウント名:
パスワード:
同じく linux カーネルで 5000台のサーバで、1週間に1回くらいのペースで起こるバグを調査したことあるけど、すごい大変だった。
おれだったら宇宙線のせいにするかそういうもんだと諦めて運用でカバーする方法を探る
何の徴候もなく死んでくれれば、ハード故障とか宇宙線とかのせいにもできたんだけどねー。毎回場所が違うけど、どれも明らかにカーネルのバグっぽい死亡メッセージ出してから死ぬ。当然ながらディストリビュータは「再現できない」で終わり。運用スタッフでは対応できないので、詳しいやつ呼び出せってなって、深夜や休日でも週1のペースで呼び出される。めんどうなやつ。
むかーし昔、Linuxをインストールしたサーバを製造している場所で仕事をしていましたが、保守契約があるお客様からそういう話があったら、dump がどこそこに出てるので提供してください。bug があったので修正版カーネルを提供いたします。って個別にビルドして提供してたけど、最近は品質下がったのかなぁ
単価が下がったのかも
自分も諦めそうなバグだなあ。解決したような感じなのでどうやって糸口を見つけたのか聞いてみたい。
1. 発生か所はバラついてるんだけど、発生か所や運用状況に基いて関係しそうなところ全部にログ出力や情報追加などを仕込んだ特殊カーネルを準備して全台を入れ換えて発生を待つ (ライブマイグレーションでタスクを一時的に別のサーバに逃がしてその間に再起動)2. 発生したら、その時出力された情報を元にさらに場所を絞り込んで、カーネルを修正して入れ換えという地味な作業を繰り返す3. 原因っぽいものが特定できたら、対策(したつもりの)カーネルを準備して半分だけ入れ換えて発生頻度を見る4. 次に対策した半分を元に戻し、対策してなかった半分を対策したものに入れ換えて発生頻度を見る (ハードや実行タスクの影響の可能性を排除するため)5. 対策版と未対策版に発生頻度に違いがあれば原因に近い何かであることが確定
(この時のはロックのレース・コンディションだった。ロックの場所じゃなくて、ずっと先のリソースのアクセス中でこけるので特定がやっかいなやつ。それも似たようなのが2個所あって、1か所の対策では頻度が減るだけで直らなかった)
これは嬉しい。貴重な話をありがとうございます。
ライブマイグレーションを使われているということは既に稼働している本番環境でのデバッグということで、さぞかし神経をすり減らすような仕事だったんでしょう。今更ながら本当にお疲れさまでした。
4の作業には目からウロコが落ちました。わざわざ問題があるものに戻すという発想はなかったです。でも理由も納得なプロフェッショナルな仕事ですね。
大昔にUNIXのドライバを書いたときに排他制御のために使うプライオリティレベルの設定に関係するバグで悩んだことを思い出しました。
5000台のサーバとなると自前のテスト環境ではなく顧客先の本番環境だろうし、プレッシャーが半端なさそうで想像するだけで胃が痛くなってきそうだw
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
発生頻度低いとたいへん (スコア:2, 参考になる)
同じく linux カーネルで 5000台のサーバで、1週間に1回くらいのペースで起こるバグを調査したことあるけど、すごい大変だった。
Re: (スコア:0)
おれだったら宇宙線のせいにするかそういうもんだと諦めて運用でカバーする方法を探る
Re: (スコア:0)
何の徴候もなく死んでくれれば、ハード故障とか宇宙線とかのせいにもできたんだけどねー。
毎回場所が違うけど、どれも明らかにカーネルのバグっぽい死亡メッセージ出してから死ぬ。
当然ながらディストリビュータは「再現できない」で終わり。
運用スタッフでは対応できないので、詳しいやつ呼び出せってなって、深夜や休日でも週1のペースで呼び出される。
めんどうなやつ。
Re: (スコア:0)
むかーし昔、Linuxをインストールしたサーバを製造している場所で仕事をしていましたが、
保守契約があるお客様からそういう話があったら、dump がどこそこに出てるので提供してください。
bug があったので修正版カーネルを提供いたします。って個別にビルドして提供してたけど、最近は品質下がったのかなぁ
Re: (スコア:0)
単価が下がったのかも
Re: (スコア:0)
自分も諦めそうなバグだなあ。
解決したような感じなのでどうやって糸口を見つけたのか聞いてみたい。
Re:発生頻度低いとたいへん (スコア:4, 興味深い)
1. 発生か所はバラついてるんだけど、発生か所や運用状況に基いて関係しそうなところ全部にログ出力や情報追加などを仕込んだ特殊カーネルを準備して全台を入れ換えて発生を待つ (ライブマイグレーションでタスクを一時的に別のサーバに逃がしてその間に再起動)
2. 発生したら、その時出力された情報を元にさらに場所を絞り込んで、カーネルを修正して入れ換えという地味な作業を繰り返す
3. 原因っぽいものが特定できたら、対策(したつもりの)カーネルを準備して半分だけ入れ換えて発生頻度を見る
4. 次に対策した半分を元に戻し、対策してなかった半分を対策したものに入れ換えて発生頻度を見る (ハードや実行タスクの影響の可能性を排除するため)
5. 対策版と未対策版に発生頻度に違いがあれば原因に近い何かであることが確定
(この時のはロックのレース・コンディションだった。ロックの場所じゃなくて、ずっと先のリソースのアクセス中でこけるので特定がやっかいなやつ。それも似たようなのが2個所あって、1か所の対策では頻度が減るだけで直らなかった)
Re: (スコア:0)
これは嬉しい。貴重な話をありがとうございます。
ライブマイグレーションを使われているということは既に稼働している本番環境でのデバッグということで、さぞかし神経をすり減らすような仕事だったんでしょう。今更ながら本当にお疲れさまでした。
4の作業には目からウロコが落ちました。わざわざ問題があるものに戻すという発想はなかったです。でも理由も納得なプロフェッショナルな仕事ですね。
大昔にUNIXのドライバを書いたときに排他制御のために使うプライオリティレベルの設定に関係するバグで悩んだことを思い出しました。
Re: (スコア:0)
5000台のサーバとなると自前のテスト環境ではなく顧客先の本番環境だろうし、プレッシャーが半端なさそうで想像するだけで胃が痛くなってきそうだw