システム管理
キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 

MC/ServiceGurd(11.13)について

hiro_760329
アドバイザー

MC/ServiceGurd(11.13)について

お世話になっております。最近当システムにおいて以下のメッセージを頻繁(1回/週)に出力しております。「cmcld: timers delayed 3.15 seconds」

「cmcld: Warning: cmcld process was unable to run for the last 3 seconds」メッセージの意味は、システム負荷や カーネルショートハングが原因でcmcldがメッセージ中の秒数の間セイフタイマの更新処理が遅れた事を表しております。しかしながら当システムの運用上、メッセージ出力の時間帯は夜間が多く、システム負荷によるものとは考えにくく、ハード部隊にも詳細に調査いただいたところも問題なしとの見解でした。パッチレベルについても確認しましたが、適用済みであるPHSS_26478から最新であるPHSS_30742の間で、本メッセージが出力される不具合の修正の報告はありませんでした。加えて、上位のバージョンであるMC/SG 11.14, 11.15の既知不具合情報に関しても調査しましたが、問題のメッセージが出力されるような不具合に関する報告はありませんでした。また、タイマの時間切れによる TOCを防ぐ手段として、カーネルハングを修正するパッチの適用が考えられますが、今回のように唯一、上記メッセージのみが発生した場合には、原因の特定が困難であり、パッチの適用による対策が有効であると判断する事は難しい状況です。現在調査が手詰まりしており、何か有力な情報などございましたらご教授いただきたく宜しくお願いします。
3 件の返信
oops
貴重なコントリビューター

MC/ServiceGurd(11.13)について

夜間にバッチ処理等は実施されてないのでしょうか?

他には夜間に NW パケットが大量に流れるとか、IO が多量にあるとかで、外部I/Fからの割り込みが多量に発生するということはないでしょうか?

システム負荷というのは、カーネルに対する負荷です。プライオリティが高い cmcld のようなプロセス(スレッド)でも、カーネルモードで動作している時にはスケジュールの割り込みがききません。

これは hp-ux に限らず、全ての UNIX がそういう実装です(Preemptable ではない)。

カーネルの不具合でカーネル内部の処理に時間を要している可能性もあるでしょうが、先に書いたように割り込み処理のような、スケジュールの割り込みを受けないハイプライオリティの処理を多量に要求されている可能性もあります。

とりあえずすぐにできることとしては、

- メッセージが出力される時間帯に共通点があるのか?

- あるのであれば、その時間帯に何をしているのか?

- 心当たりがなければ、Performance Agent(MWA)等のデータを見て、CPU、disk や NW 使用率等を観測して、何か共通点がないか確認する。

- カーネルのショートハングを修正したパッチを探す

(それなりに大変で、数があると思います)

等です。

カーネル側から調査をするためには、レスポンスセンタに問い合わせるしかないと思います。
hiro_760329
アドバイザー

MC/ServiceGurd(11.13)について

oops様

ご回答いただきましてありがとうございます。今回のメッセージ出力時間帯に共通性はなく定期的なバッチに依存するものではなさそうです。しかしながら何らかの負荷がかかっている可能性がないとも言えない為、各種リソースの負荷状況について罠かけを行います。とりあえずvmstat、sar、topを1秒間隔で取得し、メッセージ出力時にどういった負荷があるのか調査いたします。
oops
貴重なコントリビューター

MC/ServiceGurd(11.13)について

MWA(Performance Agent)や glance に比べると情報は少ないものの、定期的に発生しているようなので、まずは既存コマンドでモニターをされるのはとても良いと思います。

プロセッサの枚数にもよりますが、cmcld が動作できない状況を招きやすいものとして考えられるのは、以下のものになるかと思います。

1. 外部割込み(NW、ディスクIO等)が非常に多い

2. cmcld よりも高いリアルタイムプライオリティのプロセスが存在し、かつ、CPU をそれなりに使用する。

3. システムコールを多量に呼び出すプロセスがいる。

4. カーネルモードで消費する時間が長い(カーネルの不具合の可能性が高いと思います)。

5. HW レベルでのフォルト(cache miss 等)が多く発生している(アプリ、カーネル双方の原因が考えられます)。

要は、スケジュールの割り込みが効かない状況とういことです。

sar や vmstat だと 1 はわかりにくいと思いますが、MWA や glance があるとわかります。

2 は ps や top で発見できると思います。

3、4 は sar や vmstat だと sysCPU が高いというようにしか見えないので、どちらかを切り分けるのは難しいかと思います。

5 はかなり特定するのが難しいですが、HWのトラップに伴ってカーネルのトラップが発生している場合は、やはり sysCPU が高くなります。

プロセススケジュールをするのはカーネルなので、syCPU が高い場合に詳細を突き詰めたいのであれば、hp に問い合わせた方が良いと思います。