...

プロセスのモニタリングおよび トラブルシューティング

by user

on
Category: Documents
107

views

Report

Comments

Transcript

プロセスのモニタリングおよび トラブルシューティング
CHAPTER
7
プロセスのモニタリングおよび
トラブルシューティング
この章の内容は、次のとおりです。
•
システム マネージャ(sysmgr)
(p.7-2)
•
ウオッチドッグ システム モニタ(wdsysmon)
(p.7-2)
•
コア ダンプ(p.7-3)
•
follow コマンド(p.7-4)
•
show processes コマンド(p.7-6)
•
冗長性およびプロセスの再起動性(p.7-9)
•
プロセス ステート(p.7-10)
•
プロセス モニタリング(p.7-13)
•
CPU 使用状況(p.7-15)
•
プロセスのリロードに関するトラブルシューティング(p.7-17)
•
プロセス ブロックのトラブルシューティング(p.7-17)
Cisco IOS XR ソフトウェアは、プロセスをモジュール化する方式を採用して構築されています。プ
ロセスとは、仮想アドレス(メモリ)空間を共有するスレッドの集合です。各プロセスは、システ
ムに固有機能を提供し、1 つのプロセスに問題が発生してもシステム全体に影響を与えないように、
保護メモリ空間で実行されます。1 つのノード上でプロセスの複数のインスタンスが実行可能であ
り、各プロセス インスタンス上で複数の実行スレッドが実行可能です。
スレッドは実行単位です。各スレッドはスタックやレジスタなどの実行コンテキストを持っていま
す。スレッドは、実質的には親プロセスにより管理される “ サブプロセス ” であり、全体プロセス
の小部分を実行する役割を持ちます。たとえば、OSPF は、
「HELLO」の送受信を処理する 1 つの
スレッドです。スレッドは、システム スケジューラによって親プロセスに実行時間が割り当てられ
た場合にのみ実行可能です。複数のスレッドを持つプロセスは、マルチスレッド プロセスと呼ばれ
ます。
通常の動作環境では、プロセスは Cisco IOS XR ソフトウェアにより自動的に管理されます。プロセ
スは、ルータのランニング コンフィギュレーションに従って起動、停止、再起動が行われます。さ
らに、プロセスの再起動と自動切り替え時にチェックポイント機能が働いて、プロセスのパフォー
マ ン ス が 最 適 化 さ れ ま す。プ ロ セ ス の 詳 細 に つ い て は、
『Cisco IOS XR System Management
Configuration Guide』を参照してください。
Cisco IOS XR トラブルシューティング
OL-11138-02-J
7-1
第7章
プロセスのモニタリングおよびトラブルシューティング
システム マネージャ(sysmgr)
システム マネージャ(sysmgr)
各プロセスには、起動時に Job ID(JID)が割り当てられます。プロセスの起動、停止、およびそ
の後の再起動によっても JID は変わりません。各プロセスには、起動時に Process ID(PID)も割り
当てられますが、この PID はプロセスが停止されて再起動されると変わります。
システム マネージャ(sysmgr)は、基本プロセスであり、システムの基礎を成しています。sysmgr
は、システム上のほとんどすべてのプロセスを対象に、モニタリング、起動、停止、および再起動
を行う役割があります。プロセスの再起動はあらかじめ定義されており(respawn フラグのオン / オ
フ)、sysmgr はそれに従います。sysmgr はすべてのプロセスの親プロセスです。システムのブート
時にコンフィギュレーションにより起動されます。各ノードでは sysmgr の 2 つのインスタンスが
実行されて、ホットスタンバイ プロセスのレベルの冗長性が提供されます。各アクティブ プロセ
スは SysDB に登録され、sysmgr アクティブ プロセスにより起動されると、実行時に sysmgr に通知
されます。sysmgr アクティブ プロセスが停止すると、スタンバイ プロセスがアクティブ ステート
を引き継ぎ、新しいスタンバイ プロセスが生成されます。
ラインカード(LC)上で動作する sysmgr は、そのノードに関連するプロセス生成、再起動、コア
ダンプなど、すべてのシステム管理作業を処理します。
sysmgr 自体はブート時に初期化プロセスによって起動されます。初期化プロセスは、sysmgr が起動
すると、初期化時に起動したすべてのプロセスの所有権を sysmgr に引き継いで終了します。
ウオッチドッグ システム モニタ(wdsysmon)
ウオッチドッグ システム モニタ(wdsysmon)は、プロセスに関する履歴データを保持し、この情
報をフォルト ディテクタ ダイナミック リンク ライブラリ(DLL)に書き込みます。書き込まれた
情報は、管理機能を持つアプリケーションで照会することができます。wdsysmon に関する詳細に
ついては、第 8 章「メモリのトラブルシューティング」の「ウオッチドッグ システム モニタ
(wdsysmon)」
(p.8-2)を参照してください。
wdsysmon は、1 分ごとにカーネルをポーリングしてプロセス データを照会します。このデータは
fm_fd_wdsysmon.dll(フォルト ディテクタ)が維持するデータベースに保存され、wdsysmon により
ロードされます。
デットロックの検出
プロセス データを伴ってスレッド ステートが戻されるので、wdsysmon はデッドロックの検出を試
行できます。wdsysmon は、特にミューテックス デッドロックとローカル Inter-Process Communication
(IPC; プロセス間通信)のハング状態を探します。検出できるのはローカルの IPC デッドロックの
みです。デッドロックを検出すると、デバッグ情報を disk0:/wdsysmon_debug にまとめます。
デッドロック状態のプロセスは、processes restart コマンドを使用して手動で停止と再起動ができ
ます。
ハングの検出
システムにイベント マネージャが生成されると、イベント マネージャ ライブラリは wdsysmon に
イベントを登録します。wdsysmon は、システム内の登録されたすべてのイベント マネージャから
の定期的な「パルス」の送信を待ち受けます。イベント マネージャからの送信が途絶えると、
wdsysmon はデバッグ スクリプトを実行します。このスクリプトにより、そのイベント マネージャ
を生成したスレッドが何を処理しているかがわかります。
Cisco IOS XR トラブルシューティング
7-2
OL-11138-02-J
第7章
プロセスのモニタリングおよびトラブルシューティング
コア ダンプ
コア ダンプ
プロセスが異常終了する際に、コア ダンプ ファイルが指定された場所に書き込まれます。コア ダ
ンプには次の情報が含まれます。
•
レジスタ情報
•
スレッド ステータス情報
•
プロセス ステータス情報
•
選抜されたメモリ セグメント
コンフィグ済みのコア ダンプ設定を表示するには、show exception コマンドを使用します。show
exception コマンドの出力には、次の複数のコマンドでコンフィグされたコア ダンプ設定が表示さ
れます。
•
exception filepath
•
exception dump-tftp-route
•
exception kernel memory
•
exception pakmem
•
exception sparse
•
exception sprsize
次に、コア ダンプ設定の例を示します。
RP/0/RP0/CPU0:router# show exception
Choice 1 path = harddisk:/coredump compress = on filename = <process_name.time>
Choice 2 path = tftp://223.255.254.254/users/xyz compress = on filename =
<process_name.time>
Exception path for choice 3 is not configured or removed
Choice fallback one path = harddisk:/dumper compress = on filename = <process_name>
Choice fallback two path = disk1:/dumper compress = on filename = <process_name>
Choice fallback three path = disk0:/dumper compress = on filename = <process_name>
Kernel dump not configured
Tftp route for kernel core dump not configured
Dumper packet memory in core dump enabled
Sparse core dump enabled
Dumper will switch to sparse core dump automatically at size 300MB
コアダンプ ファイルは dumpcore コマンドを使用して手動で生成できます。手動で実行できるコア
ダンプには次の 2 種類があります。
•
running ― サービスに影響を与えません。
•
suspended ― コア ダンプの生成中は、プロセスを一時停止します。
show context コマンドを使用すると、最近の 10 回のコアダンプ情報が表示されます。
Cisco IOS XR トラブルシューティング
OL-11138-02-J
7-3
第7章
プロセスのモニタリングおよびトラブルシューティング
follow コマンド
follow コマンド
follow コマンドは、動作中プロセス、またはプロセス内の動作中 スレッドに影響を与えることなく
デバッグできます。follow コマンドは、特に次の場合に有効です。
•
プロセス デッドロック状態、ライブロック状態、またはミューテックス状態
•
CPU 利用頻度が高い状態
•
破損する問題の原因を特定するために、メモリの内容やプロセスの変数の内容を調べる場合
•
プロセスまたはスレッドがループに入る問題を調べる場合
ライブロックは、2 つ以上のプロセスが他のプロセスのステートの変化に応答して自身のステート
を変える動作を繰り返す状態です。
follow コマンドを使用して、次の処理を指定できます。
•
任意のプロセスのすべての動作中スレッド、またはプロセスの任意のスレッドを追跡し、コア
ダンプ出力と同様の形式でスタック トレースを表示します。
•
ループに入っているプロセスを、任意のループ回数の間追跡します。
•
コマンドを 2 回繰り返す間の遅延時間を設定します。
•
このコマンドが実行されている間の、このプロセスが実行されるプライオリティを設定しま
す。
•
仮想メモリの任意の位置から任意のサイズ分、メモリの内容をダンプします。
•
対象プロセスのレジスタの値とステータス情報を表示します。
•
スレッドの実行パスのスナップショットを非同期に取得して、パフォーマンス関連の問題を調
べます。このためには、遅延時間をゼロにして繰り返し回数を多く指定します。
次に、プロセス 929034375 のライブ スレッドの例を示します。
RP/0/RP0/CPU0:router# follow process 929034375
Attaching to process pid = 929034375 (pkg/bin/bgp)
No tid specified, following all threads
DLL Loaded by this process
------------------------------DLL path
Text addr. Text size Data addr. Data size Version
/pkg/lib/libsysmgr.dll
0xfc122000 0x0000df0c 0xfc0c2b14 0x000004ac
0
/pkg/lib/libcerrno.dll
0xfc130000 0x00002f04 0xfc133000 0x00000128
0
/pkg/lib/libcerr_dll_tbl.dll 0xfc134000 0x00004914 0xfc133128 0x00000148
0
/pkg/lib/libltrace.dll
0xfc139000 0x00007adc 0xfc133270 0x00000148
0
/pkg/lib/libinfra.dll
0xfc141000 0x00033c90 0xfc1333b8 0x00000bbc
0
/pkg/lib/cerrno/libinfra_error.dll 0xfc1121dc 0x00000cd8 0xfc175000 0x000000a8 0
/pkg/lib/libios.dll
0xfc176000 0x0002dab0 0xfc1a4000 0x00002000
0
/pkg/lib/cerrno/libevent_manager_error.dll 0xfc1a6000 0x00000e88 0xfc133f74 0x00
/pkg/lib/libc.dll
0xfc1a7000 0x00079d70 0xfc221000 0x00002000
0
/pkg/lib/libsyslog.dll
0xfc223000 0x000054e0 0xfc1750a8 0x00000328
0
/pkg/lib/libplatform.dll 0xfc229000 0x0000c25c 0xfc236000 0x00002000
0
/pkg/lib/libbackplane.dll 0xfc243000 0x000013a8 0xfc1755b8 0x000000a8
0
/pkg/lib/cerrno/libpkgfs_error.dll 0xfc245000 0x00000efc 0xfc175660 0x00000088 0
/pkg/lib/libnodeid.dll
0xfc246000 0x0000a588 0xfc1756e8 0x00000248
0
/pkg/lib/libdebug.dll
0xfc29b000 0x0000fdbc 0xfc2ab000 0x00000570
0
/pkg/lib/cerrno/libdebug_error.dll 0xfc294244 0x00000db0 0xfc175c68 0x000000e8 0
/pkg/lib/lib_procfs_util.dll 0xfc2ac000 0x00004f20 0xfc175d50 0x000002a8
0
/pkg/lib/libinst_debug.dll 0xfc375000 0x0000357c 0xfc36d608 0x000006fc
0
/pkg/lib/libpackage.dll 0xfc3c8000 0x00041ad0 0xfc40a000 0x00000db4
0
/pkg/lib/libwd_evm.dll
0xfc40b000 0x00003dc4 0xfc36dd04 0x00000168
0
.
.
.
Iteration 1 of 5
------------------------------
Cisco IOS XR トラブルシューティング
7-4
OL-11138-02-J
第7章
プロセスのモニタリングおよびトラブルシューティング
follow コマンド
Current process = "pkg/bin/bgp", PID = 929034375 TID = 1
trace_back:
trace_back:
trace_back:
trace_back:
trace_back:
trace_back:
trace_back:
trace_back:
#0
#1
#2
#3
#4
#5
#6
#7
0xfc164210
0xfc14ecb8
0xfc14eac4
0xfc151f98
0xfc152154
0xfd8e16a0
0x48230db8
0x48201080
[MsgReceivev]
[msg_receivev]
[msg_receive]
[event_dispatch]
[event_block]
[bgp_event_loop]
[<N/A>]
[<N/A>]
ENDOFSTACKTRACE
Current process = "pkg/bin/bgp", PID = 929034375 TID = 2
trace_back:
trace_back:
trace_back:
trace_back:
trace_back:
trace_back:
#0
#1
#2
#3
#4
#5
0xfc164210
0xfc14ecb8
0xfc14eac4
0xfc151f98
0xfc152154
0xfc50efd8
[MsgReceivev]
[msg_receivev]
[msg_receive]
[event_dispatch]
[event_block]
[chk_evm_thread]
ENDOFSTACKTRACE
.
.
.
Cisco IOS XR トラブルシューティング
OL-11138-02-J
7-5
第7章
プロセスのモニタリングおよびトラブルシューティング
show processes コマンド
show processes コマンド
プロセス情報を表示するには、次の show processes コマンドを使用します。
•
show processes boot コマンド(p.7-6)
•
show processes startup コマンド(p.7-6)
•
show processes failover コマンド(p.7-7)
•
show processes blocked コマンド(p.7-7)
show processes boot コマンド
show processes boot コマンドを使用すると、プロセスのブート情報が表示されます。コマンドの出
力から、次のことを確認してください。
•
各プロセスの起動に要した時間
•
一連のプロセスの起動順序
•
起動が遅れたプロセスは、ブート障害またはブート時の問題が原因なのか
•
システムが想定する時間内に一連のプロセスは起動したか
RP/0/RP0/CPU0:router# show processes boot location 0/rp1/cpu0
Band
----1.0
40.0
90.0
100.0
150.0
999.0
Name
Finished
%Idle
JID
Ready Last Process
-------------- -------- -------- -------- ------- --------------------MBI
22.830 65.130%
62 22.830 insthelper
ARB
129.225 92.080%
154 106.395 dsc
ADMIN
185.140
5.950%
175 55.915 fabricq_mgr
INFRA
207.372 25.040%
165 22.232 fib_mgr
STANDBY
231.605 13.840%
104 24.233 arp
FINAL
237.942
1.590%
234
6.337 ipv6_rump
Started Level
JID Inst
Ready Process
--------- ------ -------- ---- ------- ------------------------------0.000s
0.05
80
1
0.000 wd-mbi
0.000s
1.00
57
1
0.000 dllmgr
0.000s
2.00
71
1
0.000 pkgfs
0.000s
3.00
56
1
0.000 devc-conaux
0.000s
3.00
73
1
0.000 devc-pty
0.000s
6.00
70
1
0.000 pipe
.
.
.
Last process started:
6d19h after boot. Total: 174
show processes startup コマンド
show processes startup コマンドを使用すると、起動時に作成されたプロセスのプロセス データが表
示されます。コマンドの出力から、次のことを確認してください。
•
表示されているプロセスは、ステート、起動時間、再起動ステータス、プレースメント、必須
ステータスを含めて正常か
•
各プロセスの起動に要した時間
•
一連のプロセスの起動順序
•
起動が遅れたプロセスはブート障害またはブート時の問題が原因なのか
•
システムが想定する時間内に一連のプロセスは起動したか
Cisco IOS XR トラブルシューティング
7-6
OL-11138-02-J
第7章
プロセスのモニタリングおよびトラブルシューティング
show processes コマンド
RP/0/RP0/CPU0:router# show processes startup
JID
LAST STARTED
STATE
REPLACE- MANDA- NAME(IID) ARGS
START
MENT
TORY
------------------------------------------------------------------------------81
07/05/2006 14:46:37.514 Run
1
M
wd-mbi(1)
57
07/05/2006 14:46:37.514 Run
1
M
dllmgr(1) -r 60
-u 30
72
07/05/2006 14:46:37.514 Run
1
M
pkgfs(1)
56
07/05/2006 14:46:37.514 Run
1
M
devc-conaux(1) h -d librs232.dll -m libconaux.dll -u libst16550.dll
74
07/05/2006 14:46:37.514 Run
1
M
devc-pty(1) -n 3
2
55
Not configured
None
0
M
clock_chip(1) -r
-b
71
07/05/2006 14:46:37.514 Run
1
M
pipe(1)
65
07/05/2006 14:46:37.514 Run
1
M
mqueue(1)
64
Not configured
None
0
M
cat(1) /etc/motd
73
Not configured
None
0
M
platform_dllmap(
1)
77
07/05/2006 14:46:37.514 Run
1
M
shmwin_svr(1)
60
07/05/2006 14:46:37.514 Run
1
M
devf-scrp(1) -e
0xf0000038 -m /bootflash: -s 0xfc000000,64m -r -t4 -b10
66
Not configured
None
0
M
nname(1)
69
07/05/2006 14:46:37.514 Run
1
M
pci_bus_mgr(1) o
288
07/05/2006 14:47:02.799 Run
1
M
qsm(1)
68
07/05/2006 14:46:37.514 Run
1
M
obflmgr(1)
70
07/05/2006 14:46:37.514 Run
1
M
pcmciad(1) -m /d
ev/pcmcia -d libpcmcia_gt64260disc_hba -p "cardmgrd -f"
.
.
.
------------------------------------------------------------------------------Total pcbs: 198
show processes failover コマンド
show processes failover コマンドを使用すると、プロセスのフェールオーバー情報が表示されます。
コマンド出力には、フェールオーバー後にプロセスが要した起動時間(ノードのリブート)の情報
が表示されます。プロセスの起動に遅れがなかったか確認してください。
show processes blocked コマンド
show processes blocked コマンドを使用すると、応答、送信、およびミューテックスでブロックされ
たプロセスに関する詳細情報が表示されます。
どのプロセスも一時的にブロック ステートになる可能性があるため、show processes blocked コマ
ンドを、ノードごとに時間を空けて連続して 2 回実行することを推奨します。1 回めと 2 回めでプ
ロセスがブロックされている表示がされたら、もう 1 回コマンドを実行してプロセスがブロックさ
れていることを再確認するようにしてください。
ブロック ステートが持続していることを確認するため、実行する間隔は短すぎないようにします。
たとえば、フル装備の Cisco CRS-1 8 スロット ラインカード シャーシでは、2 RP と 8LC の要求に
見合う間隔が必要です。
Cisco IOS XR トラブルシューティング
OL-11138-02-J
7-7
第7章
プロセスのモニタリングおよびトラブルシューティング
show processes コマンド
show processes blocked コマンド出力では、Reply(応答)ステートのプロセスは必ずブロックされ
ている表示になります。
RP/0/RP0/CPU0:router# show processes blocked
Jid
65546
51
51
75
75
75
75
50
334
247
65750
65752
367
65770
369
Pid Tid
8202
1
36890
2
36890
3
36893
5
36893
6
36893
7
36893
8
36899
2
172108
1
290991
2
644260054
1
662208728
1
2642149
5
662208746
1
659755249
3
Name
ksh
attachd
attachd
qnet
qnet
qnet
qnet
attach_server
tftp_server
lpts_fm
exec
more
mpls_ldp
show_processes
te_control
State Blocked-on
Reply
8200 devc-conaux
Reply
32791 eth_server
Reply
12301 mqueue
Reply
32791 eth_server
Reply
32791 eth_server
Reply
32791 eth_server
Reply
32791 eth_server
Reply
12301 mqueue
Reply
12301 mqueue
Reply 184404 lpts_pa
Reply
1 kernel
Reply
12299 pipe
Reply 2642153 lspv_server
Reply
1 kernel
Reply 2642153 lspv_server
これらのプロセスについては、正常な出力です。たとえば、次の行を見てみます。
65770 662208746
1
show_processes Reply
1
kernel
これは、show processes blocked コマンドを実行した結果です。コマンドを実行するごとにプロセス
ID(PID)は変わります。
重要なシステム プロセスまたは接続を制御する基本アプリケーション(ルーティング プロトコル
やラベル スイッチング ラベル配布プロトコル [Label Distribution Protocol; LDP] など)が、Reply、
Sent、Mutex、または Condvar ステートでブロックされている場合は、次のことを行ってください。
(注)
•
follow job または follow process コマンドでデータを収集します。これらのコマンドの詳細につ
いては、「follow コマンド」
(p.7-4)を参照してください。
•
影響を受けているプロセスに dumpcore running job-id location node-id コマンドを使用します。
dumpcore の出力は、exception choice コマンドを使用して保存場所の設定が変更されていない場
合、harddisk:/dumper にあります。
再起動することが危険なプロセスもあります。技術担当者と連絡を取り、シスコのテクニカルサ
ポートの指示に従うことを推奨します。シスコのテクニカルサポートの連絡窓口についての情報
は、
「はじめに」の「テクニカル サポート」
(p.xiii)を参照してください。
RP/0/RP0/CPU0:router# show processes blocked
Jid
65546
51
51
75
75
75
75
50
334
247
65750
65752
367
65772
65773
65774
Pid Tid
8202
1
36890
2
36890
3
36893
5
36893
6
36893
7
36893
8
36899
2
172108
1
290991
2
644260054
1
655270104
1
2642149
5
655229164
1
656842989
1
656842990
1
Name
ksh
attachd
attachd
qnet
qnet
qnet
qnet
attach_server
tftp_server
lpts_fm
exec
config
mpls_ldp
exec
more
show_processes
State Blocked-on
Reply
8200 devc-conaux
Reply
32791 eth_server
Reply
12301 mqueue
Reply
32791 eth_server
Reply
32791 eth_server
Reply
32791 eth_server
Reply
32791 eth_server
Reply
12301 mqueue
Reply
12301 mqueue
Reply 184404 lpts_pa
Reply
1 kernel
Reply 286888 devc-vty
Reply 2642153 lspv_server
Reply
1 kernel
Reply
12299 pipe
Reply
1 kernel
Cisco IOS XR トラブルシューティング
7-8
OL-11138-02-J
第7章
プロセスのモニタリングおよびトラブルシューティング
冗長性およびプロセスの再起動性
冗長性およびプロセスの再起動性
Cisco IOS XR ソフトウェアを使用するシステムでは、重大エラーの回復方法として、アプリケー
ションは主にプロセス再起動性とプロセス(アプリケーション)冗長性の 2 つを組み合わせて使用
します。
プロセスの再起動は、通常は障害回復の第 1 段階として使用されます。チェックポイントされた
データが壊れていなければ、クラッシュしたプロセスは再起動後に回復できます。必須プロセスが
何回かの再起動に失敗したり、ピア プロセスがクラッシュしたあと再起動しても回復できない場合
は、スタンバイ カードがアクティブになります。
必須プロセス以外のプロセスの場合、1 分間の再起動数に達すると、sysmgr がそのプロセスの再起
動を停止するので、手動でアプリケーションを再起動する必要があります。
コンフィギュレーションにより起動されないプロセスは、デフォルトで「必須」(ルータの動作に
重要な)プロセスとして起動されます。必須プロセスが 5 分間のウィンドウ以内に 5 回クラッシュ
した場合は、スタンバイ RP が冗長状態であれば、RP のフェールオーバーが実行されます。show
processes all コマンドを使用すると、すべてのプロセスと必須フラグを含めたプロセス ステートが
表示されます。必須フラグは、オフに切り替えられます。必須フラグの切り替えには、process
mandatory {on | off} {executable-name | job-id} [location node-id] コマンドを使用します。
Cisco IOS XR トラブルシューティング
OL-11138-02-J
7-9
第7章
プロセスのモニタリングおよびトラブルシューティング
プロセス ステート
プロセス ステート
Cisco IOS XR ソフトウェア内には、サービスを提供するサーバとサービスを利用するクライアント
があります。あるプロセスは、同じサービスを提供する複数のスレッドを持つことができます。別
なプロセスは、特定のサービスを必要とする複数のクライアントをいつでも持つことができます。
サーバが常に利用できるとは限りません。そのときにクライアントがサービスへのアクセスを要求
した場合は、サーバが空くのを待つことになります。これが、クライアントのブロック状態です。
クライアントがブロックされるケースには、ミューテックスなどのリソースを待っている場合、
サーバが応答しない場合などがあります。
次に、show process ospf コマンドを使用して OSPF プロセスのスレッドのステータスを確認する例
を示します。
RP/0/RP0/CPU0:router# show processes ospf
Job Id: 250
PID: 299228
Executable path: /disk0/hfr-rout-3.4.0/bin/ospf
Instance #: 1
Version ID: 00.00.0000
Respawn: ON
Respawn count: 1
Max. spawns per minute: 12
Last started: Wed Nov 8 15:45:59 2006
Process state: Run
Package state: Normal
Started on config: cfg/gl/ipv4-ospf/proc/100/ord_f/default/ord_a/routerid
core: TEXT SHAREDMEM MAINMEM
Max. core: 0
Placement: ON
startup_path: /pkg/startup/ospf.startup
Ready: 3.356s
Available: 7.363s
Process cpu time: 2.648 user, 0.186 kernel, 2.834 total
JID
TID Stack pri state
HR:MM:SS:MSEC NAME
272
1
60K 10 Receive
0:00:00:0563 ospf
272
2
60K 10 Receive
0:00:00:0017 ospf
272
3
60K 10 Receive
0:00:00:0035 ospf
272
4
60K 10 Receive
0:00:02:0029 ospf
272
5
60K 10 Receive
0:00:00:0003 ospf
272
6
60K 10 Condvar
0:00:00:0001 ospf
272
7
60K 10 Receive
0:00:00:0000 ospf
-------------------------------------------------------------------------------
ospf プロセスには、JID として 250 が付与されています。この JID はルータが稼働中に変わること
はありません。この ospf プロセスにはスレッドが 7 つあります。それぞれ独自のスレッド ID(TID)
を持っています。各スレッドには、スタック空間、プライオリティ、およびスレッド ステートが列
記されています。スレッド ステートの一覧を表 7-1 に示します。
同期式メッセージ パッシング
メッセージ パッシングのライフ サイクルは、次のとおりです。
1. サーバがメッセージ チャネルを作成
2. クライアントがサーバのチャネルに接続(posix open に相当)
3. クライアントがメッセージをサーバに送信(MsgSend)し、応答を待ち、ブロック
4. サーバがクライアントからメッセージを受信(MsgReceive)し、メッセージを処理し、クライ
アントに応答
5. クライアントがブロックを解除し、サーバからの応答を処理
Cisco IOS XR トラブルシューティング
7-10
OL-11138-02-J
第7章
プロセスのモニタリングおよびトラブルシューティング
プロセス ステート
このブロッキング クライアント / サーバ モデルは同期式メッセージ パッシングです。これは、ク
ライアントがメッセージを送信しブロックすることを意味します。サーバはメッセージを受信し、
それを処理してクライアントに応答を返します。それによってクライアントはブロックを解除しま
す。詳細な流れは次のとおりです。
1. サーバが RECEIVE ステートで待機する
2. クライアントがサーバにメッセージを送信し、BLOCKED ステートになる
3. サーバがメッセージを受信し、ブロックを解除する(RECEIVE ステートで待機していた場合)
4. クライアントが REPLY ステートに移行する
5. サーバが RUNNING ステートに移行する
6. サーバがメッセージを処理する
7. サーバがクライアントに応答する
8. クライアントがブロックを解除する
クライアントおよびサーバの現在のステートを表示するには、show processes コマンドを使用しま
す。表 7-1 にスレッド ステートを示します。
ブロックされたプロセスおよびプロセス ステート
ブロックされたステートにあるプロセスを表示するには、show processes blocked コマンドを使用し
ます。
同期式メッセージ パッシングによって、異なるスレッド間でのプロセス間通信のライフ サイクル
を追跡できます。スレッドは、いつの時点においても何らかのステートにあります。ブロック ス
テートは、問題の兆候を意味することがあります。ただし、ブロック ステートだからといって、た
だちにそのスレッドに問題があるわけではありません。通常、スレッドがブロック状態になること
もあります。show processes blocked コマンドを使用すると、オペレーティング システム関連の問
題をトラブルシューティングする良い手がかりが得られることがあります。たとえば、CPU の利用
頻度が高い場合、show processes blocked コマンドを使用して、何か異常な状況(ルータの機能上、
正常でないもの)がないか確認します。このようにすると、プロセスのライフ サイクルをトラブル
シューティングする際に、比較をするためのベースラインが得られます。
スレッドは、いつの時点においても何らかのステートにあります。表 7-1 にスレッド ステートを示
します。
表 7-1
スレッド ステート
ステート名
意味
DEAD
デッド状態です。カーネルはスレッドのリソースの解放を待っています。
RUNNING
CPU 上でアクティブに実行中です。
READY
CPU 上で実行中ではありませんが、実行の用意が整っています。
STOPPED
一時停止中(SIGSTOP シグナル)です。
SEND
サーバがメッセージを受信するのを待っています。
RECEIVE
クライアントがメッセージを送信するのを待っています。
REPLY
サーバがメッセージに応答するのを待っています。
STACK
スタックがさらに割り当てられるのを待っています。
WAITPAGE
プロセス マネージャがページ フォルトを解決するのを待っています。
SIGSUSPEND
シグナルを待っています。
SIGWAITINFO
シグナルを待っています。
Cisco IOS XR トラブルシューティング
OL-11138-02-J
7-11
第7章
プロセスのモニタリングおよびトラブルシューティング
プロセス ステート
表 7-1
スレッド ステート(続き)
ステート名
意味
NANOSLEEP
一定時間スリープ状態です。
MUTEX
ミューテックスの取得を待っています。
CONDVAR
条件変数にシグナルが送られるのを待っています。
JOIN
別なスレッドの終了を待っています。
INTR
割り込みを待っています。
SEM
セマフォの取得を待っています。
Cisco IOS XR トラブルシューティング
7-12
OL-11138-02-J
第7章
プロセスのモニタリングおよびトラブルシューティング
プロセス モニタリング
プロセス モニタリング
大量の sysmgr イベントが /tmp/sysmgr.log に保存されます。このログは循環バッファなので、トラ
ブルシューティングに役立ちます。異常終了したプロセスの概要を表示するには、show processes
aborts location node-id all コマンドまたは show sysmgr trace verbose | include PROC_ABORT コマン
ドを使用します。
システム上のすべてのプロセスは sysmgr によってすでにモニタされているので、外部の管理ツー
ルで重要プロセスをモニタする必要はありません。ただし、show fault manager metric process pid
location node-id コマンドを使用して、定期的(毎日 2 回程度)にクリティカルなプロセスを確認す
るとよいでしょう。このコマンド出力には、プロセスが異常終了したことおよびその理由などの情
報が表示されます。
次に、クリティカル プロセスである OSPF の詳細情報の例を示します。プロセスが異常終了した回
数と、過去の所定の期間内における異常終了の回数を確認してください。
RP/0/RP0/CPU0:router# show fault manager metric process ospf location
=====================================
job id: 269, node name: 0/RP0/CPU0
process name: ospf, instance: 1
-------------------------------last event type: process start
recent start time: Wed Jul 5 15:17:48 2006
recent normal end time: n/a
recent abnormal end time: n/a
number of times started: 1
number of times ended normally: 0
number of times ended abnormally: 2
most recent 10 process start times:
-------------------------Wed Jul 5 15:17:48 2006
-------------------------most recent 10 process end times and types:
cumulative process available time: 162 hours 20 minutes 51 seconds 452 milliseco
nds
cumulative process unavailable time: 0 hours 0 minutes 0 seconds 0 milliseconds
process availability: 1.000000000
number of abnormal ends within the past 60 minutes (since reload): 0
number of abnormal ends within the past 24 hours (since reload): 0
number of abnormal ends within the past 30 days (since reload): 2
重要なシステムプロセスには、次のものがあります。RP 上では qnet、gsp、qsm、redcon、netio、
ifmgr、fgid_aggregator、fgid_server、fgid_allocator、fsdb_server、fsdb_aserver、fabricq_mgr、fia_driver、
shelfmgr、および lrd。ラインカード上では fabricq_mgr、ingressq、egressq、pse_driver、fia_driver、
cpuctrl、および pla_server です。
クリティカル プロセスまたは重要プロセスがブロック ステートになっていないか、定期的に確認
することも重要です。プロセスのブロック ステートを確認する詳細については、
「show processes
blocked コマンド」(p.7-7)を参照してください。
Cisco IOS XR トラブルシューティング
OL-11138-02-J
7-13
第7章
プロセスのモニタリングおよびトラブルシューティング
プロセス モニタリング
プロセス モニタリング コマンド
プロセスをモニタするには、次のコマンドを使用します。
(注)
•
top コマンド ― システムの CPU 使用状況の統計情報をリアルタイムで表示します。「top コマ
ンド」(p.1-12)を参照してください。
•
show processes pidin コマンド ― すべてのプロセスの Raw 出力を、ステートを含めて表示しま
す。
•
show processes blocked コマンド ― 応答、送信、およびミューテックスでブロックされたプロ
セスに関する詳細情報を表示します。「show processes blocked コマンド」(p.7-7)を参照してく
ださい。
CPU の使用状況ごとに上位プロセスとスレッドを確認するには、monitor processes および monitor
threads コマンドを使用します。
Cisco IOS XR トラブルシューティング
7-14
OL-11138-02-J
第7章
プロセスのモニタリングおよびトラブルシューティング
CPU 使用状況
CPU 使用状況
wdsysmon は継続的にシステムを監視し、ハイ プライオリティのスレッドによってロー プライオリ
ティのスレッドが CPU 不足にならないようにし、ハイ プライオリティによる CPU 占有状況から回
復させる手順を提供します。wdsysmon は CPU ホグ状態のプロセスを確認すると、そのプロセスを
終了させ、デバッグに役立つコアダンプを取得して指定されたデバイスに保存します。高い CPU 使
用状況をトラブルシューティングする方法の詳細については、「プロセスのリロードに関するトラ
ブルシューティング」(p.7-17)を参照してください。
wdsysmon が CPU ホグ状態を検出すると、Syslog メッセージが生成されます。次の Syslog メッセー
ジの推奨処置に従ってください。
メッセージ:%HA-HA_WD-6-CPU_HOG_1 CPU hog:cpu [dec]'s sched count is [dec].
RP/0/RP0/CPU0:Dec 22 16:16:34.791 : wdsysmon[331]: %HA-HA_WD-6-CPU_HOG_1 : CPU hog:
cpu 1's sched count is 0.
wdsysmon は CPU 不足の状態を検出しました。ハイ プライオリティのプロセスが、ループ状態にお
ちいっている可能性があります。
「sched count」は、wdsysmon watcher スレッドが最後に実行されて
から、wdsysmon ticker スレッドがスケジュールされた回数です。
保存されているログを含めて、ハイ プライオリティの CPU ホグの形跡がないか、システム ステー
タスを確認してください。システム ステータスの確認方法の詳細については、「プロセスのリロー
ドに関するトラブルシューティング」(p.7-17)を参照してください。
メ ッ セ ー ジ:%HA-HA_WD-6-CPU_HOG_2 CPU hog:cpu [dec]'s ticker last ran [dec].[dec]
seconds ago.
RP/0/RP0/CPU0:Dec 22 16:16:34.791 : wdsysmon[331]: %HA-HA_WD-6-CPU_HOG_2 : CPU hog:
cpu 1's ticker last ran 3.965 seconds ago.
wdsysmon は CPU 不足の状態を検出しました。ハイ プライオリティのプロセスが、ループ状態にお
ちいっている可能性があります。
保存されているログを含めて、ハイ プライオリティの CPU ホグの形跡がないか、システム ステー
タスを確認してください。システム ステータスの確認方法の詳細については、「プロセスのリロー
ドに関するトラブルシューティング」(p.7-17)を参照してください。
メッセージ:%HA-HA_WD-6-CPU_HOG_3 Rolling average of scheduling times:[dec].[dec].
RP/0/RP0/CPU0:Dec 22 16:16:34.791 : wdsysmon[331]: %HA-HA_WD-6-CPU_HOG_3 : Rolling
average of scheduling times: 0.201.
wdsysmon は CPU 不足の状態を検出しました。ハイ プライオリティのプロセスが、ループ状態にお
ちいっている可能性があります。ローリング平均が高い値を示す場合は、定期的なプロセスがスケ
ジュールされていないことを意味します。
保存されているログを含めて、ハイ プライオリティの CPU ホグの形跡がないか、システム ステー
タスを確認してください。システム ステータスの確認方法の詳細については、「プロセスのリロー
ドに関するトラブルシューティング」(p.7-17)を参照してください。
Cisco IOS XR トラブルシューティング
OL-11138-02-J
7-15
第7章
プロセスのモニタリングおよびトラブルシューティング
CPU 使用状況
メッセージ:%HA-HA_WD-6-CPU_HOG_4 Process [chars] pid [dec] tid [dec] prio [dec] using
[dec]% is the top user of CPU
RP/0/RP0/CPU0:Dec 22 16:16:35.813 : wdsysmon[331]: %HA-HA_WD-6-CPU_HOG_4 : Process
wd_test pid 409794 tid 2 prio 14 using 99% is the top user of CPU.
このメッセージは、CPU ホグ ディテクタが動作したあとに表示されます。メッセージには、CPU
上位ユーザのうち最も使用率の高いスレッドが使用している CPU の割合が示されています。シス
テム ステータスの確認方法の詳細については、「プロセスのリロードに関するトラブルシューティ
ング」(p.7-17)を参照してください。
show watchdog trace コマンドを使用すると、CPU ホグの可能性に関する追加情報が表示されます。
CPU ホグ状態が 30 秒以上続くと、そのノードはリセットされます。リセットの直前には、次のよ
うな記録がログに残されます。
RP/0/RP0/CPU0:Dec 20 10:36:08.990 : wdsysmon[367]: %HA-HA_WD-1-CURRENT_STATE :
Persistent Hog detected for more than 30 seconds
CPU ホグ状態が持続してノードがリセットされた場合は、シスコのテクニカルサポートにご連絡く
ださい。シスコのテクニカルサポートの連絡窓口についての情報は、「はじめに」の「テクニカル
サポート」(p.xiii)を参照してください。コンソール上またはシステム ログに出力されたエラー
メッセージをそのままコピーして、収集した情報とともにテクニカルサポートに提出してくださ
い。
Cisco IOS XR トラブルシューティング
7-16
OL-11138-02-J
第7章
プロセスのモニタリングおよびトラブルシューティング
プロセスのリロードに関するトラブルシューティング
プロセスのリロードに関するトラブルシューティング
プロセスのリロードに関するトラブルシューティングを行うには、シスコのテクニカルサポートに
ご連絡ください。シスコのテクニカルサポートの連絡窓口についての情報は、「はじめに」の「テ
クニカル サポート」(p.xiii)を参照してください。
シスコのテクニカルサポートにご連絡いただく前に、次の情報を収集してください。
•
show context all location all コマンドの出力
•
show version コマンドの出力
•
show dll コマンドの出力
•
show log コマンドの出力
•
コア ダンプ ファイルを収集します。コア ダンプの収集方法に関する詳細については、「show
context コマンド」(p.1-12)を参照してください。
プロセス ブロックのトラブルシューティング
プロセス ブロックをトラブルシューティングする手順は、次のとおりです。
手順概要
1. show processes blocked location node-id
2. follow job job-id location node-id
3. process restart job-id location node-id
手順詳細
ステップ 1
コマンドまたは操作
説明
show processes blocked location node-id
show processes blocked コマンドを数回使用し、出力を比較
して長時間ブロックされているプロセスがないかどうか確
認します。
RP/0/RP0/CPU0:router# show processes
blocked location 0/1/cpu0
ステップ 2
follow job job-id location node-id
RP/0/RP0/CPU0:router# follow job 234
location 0/1/cpu0
•
Name の欄には、ブロックされているプロセス名が表示
されます。
•
Blocked-on 欄には、
ブロックされているプロセスの PID
が表示されます。
•
State 欄に Mutex が表示される場合は、プロセス内のス
レッドがほかのスレッドを待っています。その場合、
Blocked-on 欄には PID ではなく PID と TID が表示され
ます。
•
ブロックされているプロセスは、ほかのプロセスに
よってブロックされることがあります。プロセスが別
なプロセスによってブロックされている場合は、ブ
ロッキングのチェーンを追跡し、ブロックしている根
源のプロセスを見つける必要があります。ブロッキン
グのチェーンを追跡するには、ステップ 2 に進みます。
他のプロセスをブロックしている根源のプロセスを追跡し
ます。次のコマンドは、プロセスが定期的に実行している
コード部分を示します。
Cisco IOS XR トラブルシューティング
OL-11138-02-J
7-17
第7章
プロセスのモニタリングおよびトラブルシューティング
プロセス ブロックのトラブルシューティング
ステップ 3
コマンドまたは操作
説明
process restart job-id location node-id
プロセスを再起動します。
RP/0/RP0/CPU0:router# process restart
234 location 0/1/cpu0
問題が解決しない場合は、シスコのテクニカルサポートに
ご連絡ください。シスコのテクニカルサポートの連絡窓口
についての情報は、
「はじめに」の「テクニカル サポート」
(p.xiii)を参照してください。
シスコのテクニカルサポートが参照しますので、次の情報
を収集してください。
•
show processes blocked location node-id command output
•
follow job job-id location node-id command output
•
show version コマンドの出力
•
show dll コマンドの出力
•
show configuration command output
•
show logging command output
•
次のファイルの内容:
disk0:/wdsysmon_debug/debug_env. number(ある場合)
Cisco IOS XR トラブルシューティング
7-18
OL-11138-02-J
Fly UP