Javaトラブルに応じた初動対応のまとめ - n-agetsumaの日記
Javaトラブルでは『情報がなくて、再現もなかなかしません』といった状況に陥ることがある。このような状況を回避するために、以下の3つの代表的なトラブルを例に、アプリケーションサーバを再起動する前に何を取得すれば良いのかをまとめてみる。 アプリケーションから応答がない アプリケーションが遅い ヒープメモリが足りない(OutOfMemoryErrorの発生) アプリケーションから応答がない 取得する情報 スレッドダンプ データ取得方法 スレッドダンプとは、コマンド実行時点でのJavaスレッド実行状態を出力したものである。応答がない場合、何らかの要因によりどこかで処理が止まっていることが想定される。スレッドダンプは『どこで止まっているのか？』を切り分けるのに大切な情報である。 取得方法はJDKのバージョンによって色々ある。 kill -3 <pid> (少なくとも1.4.2にはある〜JDK7でも
バグの数は予測できるのか？ 発想は斬新だけど評判の悪い「池の中の魚」モデル
バグの数は予測できるのか？ 発想は斬新だけど評判の悪い「池の中の魚」モデル：山浦恒央の“くみこみ”な話（48） プログラマーの永遠の課題「プログラム中の残存バグ数の推定」に迫るシリーズ。今回は、エンジニアの基本姿勢から逸脱した、一種のトンデモ推定法である「キャプチャー・リキャプチャー・モデル（別名、ソフトウェア版『池の中の魚』モデル」を取り上げます。 コーディングが終わり、コンパイルエラーも消え、いざデバッグ工程に突入――。このとき、「プログラムの中に隠れているバグの総数を正確に推定できたらなぁ……」と考えたことはありませんか？ こう考えるのは何もプログラマーだけではありません。プロジェクトマネジャーも、プロジェト管理や品質制御の観点から、バグ総数を高精度で予測することを夢見ています。 というわけで、新シリーズでは、この「ソフトウェア中の残存バグ数の推定」をテーマに取り上げ、今回から数回に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
