Cisco IOS XR トラブルシューティング Cisco IOS XR Software Release 3.4
プロセスのモニタリングおよび トラブルシューティング
プロセスのモニタリングおよびトラブルシューティング
発行日;2012/02/06 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 1MB) | フィードバック

目次

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

システム マネージャ(sysmgr)

ウオッチドッグ システム モニタ(wdsysmon)

デットロックの検出

ハングの検出

コア ダンプ

follow コマンド

show processes コマンド

show processes boot コマンド

show processes startup コマンド

show processes failover コマンド

show processes blocked コマンド

冗長性およびプロセスの再起動性

プロセス ステート

同期式メッセージ パッシング

ブロックされたプロセスおよびプロセス ステート

プロセス モニタリング

プロセス モニタリング コマンド

CPU 使用状況

プロセスのリロードに関するトラブルシューティング

プロセス ブロックのトラブルシューティング

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

この章の内容は、次のとおりです。

「システム マネージャ(sysmgr)」

「ウオッチドッグ システム モニタ(wdsysmon)」

「コア ダンプ」

「follow コマンド」

「show processes コマンド」

「冗長性およびプロセスの再起動性」

「プロセス ステート」

「プロセス モニタリング」

「CPU 使用状況」

「プロセスのリロードに関するトラブルシューティング」

「プロセス ブロックのトラブルシューティング」

Cisco IOS XR ソフトウェアは、プロセスをモジュール化する方式を採用して構築されています。プロセスとは、仮想アドレス(メモリ)空間を共有するスレッドの集合です。各プロセスは、システムに固有機能を提供し、1 つのプロセスに問題が発生してもシステム全体に影響を与えないように、保護メモリ空間で実行されます。1 つのノード上でプロセスの複数のインスタンスが実行可能であり、各プロセス インスタンス上で複数の実行スレッドが実行可能です。

スレッドは実行単位です。各スレッドはスタックやレジスタなどの実行コンテキストを持っています。スレッドは、実質的には親プロセスにより管理される"サブプロセス"であり、全体プロセスの小部分を実行する役割を持ちます。たとえば、OSPF は、「HELLO」の送受信を処理する 1 つのスレッドです。スレッドは、システム スケジューラによって親プロセスに実行時間が割り当てられた場合にのみ実行可能です。複数のスレッドを持つプロセスは、マルチスレッド プロセスと呼ばれます。

通常の動作環境では、プロセスは Cisco IOS XR ソフトウェアにより自動的に管理されます。プロセスは、ルータのランニング コンフィギュレーションに従って起動、停止、再起動が行われます。さらに、プロセスの再起動と自動切り替え時にチェックポイント機能が働いて、プロセスのパフォーマンスが最適化されます。プロセスの詳細については、『 Cisco IOS XR System Management Configuration Guide 』を参照してください。

システム マネージャ(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 に関する詳細については、「メモリのトラブルシューティング」「ウオッチドッグ システム モニタ(wdsysmon)」を参照してください。

wdsysmon は、1 分ごとにカーネルをポーリングしてプロセス データを照会します。このデータは fm_fd_wdsysmon.dll(フォルト ディテクタ)が維持するデータベースに保存され、wdsysmon によりロードされます。

デットロックの検出

プロセス データを伴ってスレッド ステートが戻されるので、wdsysmon はデッドロックの検出を試行できます。wdsysmon は、特にミューテックス デッドロックとローカル Inter-Process Communication(IPC; プロセス間通信)のハング状態を探します。検出できるのはローカルの IPC デッドロックのみです。デッドロックを検出すると、デバッグ情報を disk0:/wdsysmon_debug にまとめます。

デッドロック状態のプロセスは、 processes restart コマンドを使用して手動で停止と再起動ができます。

ハングの検出

システムにイベント マネージャが生成されると、イベント マネージャ ライブラリは wdsysmon にイベントを登録します。wdsysmon は、システム内の登録されたすべてのイベント マネージャからの定期的な「パルス」の送信を待ち受けます。イベント マネージャからの送信が途絶えると、wdsysmon はデバッグ スクリプトを実行します。このスクリプトにより、そのイベント マネージャを生成したスレッドが何を処理しているかがわかります。

コア ダンプ

プロセスが異常終了する際に、コア ダンプ ファイルが指定された場所に書き込まれます。コア ダンプには次の情報が含まれます。

レジスタ情報

スレッド ステータス情報

プロセス ステータス情報

選抜されたメモリ セグメント

コンフィグ済みのコア ダンプ設定を表示するには、 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 回のコアダンプ情報が表示されます。

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
------------------------------
 
Current process = "pkg/bin/bgp", PID = 929034375 TID = 1
 
trace_back: #0 0xfc164210 [MsgReceivev]
trace_back: #1 0xfc14ecb8 [msg_receivev]
trace_back: #2 0xfc14eac4 [msg_receive]
trace_back: #3 0xfc151f98 [event_dispatch]
trace_back: #4 0xfc152154 [event_block]
trace_back: #5 0xfd8e16a0 [bgp_event_loop]
trace_back: #6 0x48230db8 [<N/A>]
trace_back: #7 0x48201080 [<N/A>]
 
ENDOFSTACKTRACE
 
 
Current process = "pkg/bin/bgp", PID = 929034375 TID = 2
 
trace_back: #0 0xfc164210 [MsgReceivev]
trace_back: #1 0xfc14ecb8 [msg_receivev]
trace_back: #2 0xfc14eac4 [msg_receive]
trace_back: #3 0xfc151f98 [event_dispatch]
trace_back: #4 0xfc152154 [event_block]
trace_back: #5 0xfc50efd8 [chk_evm_thread]
 
ENDOFSTACKTRACE
.
.
.

show processes コマンド

プロセス情報を表示するには、次の show processes コマンドを使用します。

「show processes boot コマンド」

「show processes startup コマンド」

「show processes failover コマンド」

「show processes blocked コマンド」

show processes boot コマンド

show processes boot コマンドを使用すると、プロセスのブート情報が表示されます。コマンドの出力から、次のことを確認してください。

各プロセスの起動に要した時間

一連のプロセスの起動順序

起動が遅れたプロセスは、ブート障害またはブート時の問題が原因なのか

システムが想定する時間内に一連のプロセスは起動したか

RP/0/RP0/CPU0:router# show processes boot location 0/rp1/cpu0
 
Band Name Finished %Idle JID Ready Last Process
----- -------------- -------- -------- -------- ------- ---------------------
1.0 MBI 22.830 65.130% 62 22.830 insthelper
40.0 ARB 129.225 92.080% 154 106.395 dsc
90.0 ADMIN 185.140 5.950% 175 55.915 fabricq_mgr
100.0 INFRA 207.372 25.040% 165 22.232 fib_mgr
150.0 STANDBY 231.605 13.840% 104 24.233 arp
999.0 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 コマンドを使用すると、起動時に作成されたプロセスのプロセス データが表示されます。コマンドの出力から、次のことを確認してください。

表示されているプロセスは、ステート、起動時間、再起動ステータス、プレースメント、必須ステータスを含めて正常か

各プロセスの起動に要した時間

一連のプロセスの起動順序

起動が遅れたプロセスはブート障害またはブート時の問題が原因なのか

システムが想定する時間内に一連のプロセスは起動したか

RP/0/RP0/CPU0:router# show processes startup
 
JID LAST STARTED STATE RE- PLACE- 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 の要求に見合う間隔が必要です。

show processes blocked コマンド出力では、Reply(応答)ステートのプロセスは必ずブロックされている表示になります。

RP/0/RP0/CPU0:router# show processes blocked
 
Jid Pid Tid Name State Blocked-on
65546 8202 1 ksh Reply 8200 devc-conaux
51 36890 2 attachd Reply 32791 eth_server
51 36890 3 attachd Reply 12301 mqueue
75 36893 5 qnet Reply 32791 eth_server
75 36893 6 qnet Reply 32791 eth_server
75 36893 7 qnet Reply 32791 eth_server
75 36893 8 qnet Reply 32791 eth_server
50 36899 2 attach_server Reply 12301 mqueue
334 172108 1 tftp_server Reply 12301 mqueue
247 290991 2 lpts_fm Reply 184404 lpts_pa
65750 644260054 1 exec Reply 1 kernel
65752 662208728 1 more Reply 12299 pipe
367 2642149 5 mpls_ldp Reply 2642153 lspv_server
65770 662208746 1 show_processes Reply 1 kernel
369 659755249 3 te_control 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 コマンド」を参照してください。

影響を受けているプロセスに dumpcore running job-id location node-id コマンドを使用します。dumpcore の出力は、 exception choice コマンドを使用して保存場所の設定が変更されていない場合、harddisk:/dumper にあります。


) 再起動することが危険なプロセスもあります。技術担当者と連絡を取り、シスコのテクニカルサポートの指示に従うことを推奨します。シスコのテクニカルサポートの連絡窓口についての情報は、「はじめに」「テクニカル サポート」を参照してください。


RP/0/RP0/CPU0:router# show processes blocked
 
Jid Pid Tid Name State Blocked-on
65546 8202 1 ksh Reply 8200 devc-conaux
51 36890 2 attachd Reply 32791 eth_server
51 36890 3 attachd Reply 12301 mqueue
75 36893 5 qnet Reply 32791 eth_server
75 36893 6 qnet Reply 32791 eth_server
75 36893 7 qnet Reply 32791 eth_server
75 36893 8 qnet Reply 32791 eth_server
50 36899 2 attach_server Reply 12301 mqueue
334 172108 1 tftp_server Reply 12301 mqueue
247 290991 2 lpts_fm Reply 184404 lpts_pa
65750 644260054 1 exec Reply 1 kernel
65752 655270104 1 config Reply 286888 devc-vty
367 2642149 5 mpls_ldp Reply 2642153 lspv_server
65772 655229164 1 exec Reply 1 kernel
65773 656842989 1 more Reply 12299 pipe
65774 656842990 1 show_processes Reply 1 kernel

冗長性およびプロセスの再起動性

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 ソフトウェア内には、サービスを提供するサーバとサービスを利用するクライアントがあります。あるプロセスは、同じサービスを提供する複数のスレッドを持つことができます。別なプロセスは、特定のサービスを必要とする複数のクライアントをいつでも持つことができます。サーバが常に利用できるとは限りません。そのときにクライアントがサービスへのアクセスを要求した場合は、サーバが空くのを待つことになります。これが、クライアントのブロック状態です。クライアントがブロックされるケースには、ミューテックスなどのリソースを待っている場合、サーバが応答しない場合などがあります。

次に、 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. クライアントがブロックを解除し、サーバからの応答を処理

このブロッキング クライアント/サーバ モデルは同期式メッセージ パッシングです。これは、クライアントがメッセージを送信しブロックすることを意味します。サーバはメッセージを受信し、それを処理してクライアントに応答を返します。それによってクライアントはブロックを解除します。詳細な流れは次のとおりです。

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

シグナルを待っています。

NANOSLEEP

一定時間スリープ状態です。

MUTEX

ミューテックスの取得を待っています。

CONDVAR

条件変数にシグナルが送られるのを待っています。

JOIN

別なスレッドの終了を待っています。

INTR

割り込みを待っています。

SEM

セマフォの取得を待っています。

プロセス モニタリング

大量の 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 コマンド」を参照してください。

プロセス モニタリング コマンド

プロセスをモニタするには、次のコマンドを使用します。

top コマンド ― システムの CPU 使用状況の統計情報をリアルタイムで表示します。「top コマンド」を参照してください。

show processes pidin コマンド ― すべてのプロセスの Raw 出力を、ステートを含めて表示します。

show processes blocked コマンド ― 応答、送信、およびミューテックスでブロックされたプロセスに関する詳細情報を表示します。「show processes blocked コマンド」を参照してください。


) CPU の使用状況ごとに上位プロセスとスレッドを確認するには、monitor processes および monitor threads コマンドを使用します。


CPU 使用状況

wdsysmon は継続的にシステムを監視し、ハイ プライオリティのスレッドによってロー プライオリティのスレッドが CPU 不足にならないようにし、ハイ プライオリティによる CPU 占有状況から回復させる手順を提供します。wdsysmon は CPU ホグ状態のプロセスを確認すると、そのプロセスを終了させ、デバッグに役立つコアダンプを取得して指定されたデバイスに保存します。高い CPU 使用状況をトラブルシューティングする方法の詳細については、「プロセスのリロードに関するトラブルシューティング」を参照してください。

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 ホグの形跡がないか、システム ステータスを確認してください。システム ステータスの確認方法の詳細については、「プロセスのリロードに関するトラブルシューティング」を参照してください。

メッセージ:%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 ホグの形跡がないか、システム ステータスを確認してください。システム ステータスの確認方法の詳細については、「プロセスのリロードに関するトラブルシューティング」を参照してください。

メッセージ:%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 ホグの形跡がないか、システム ステータスを確認してください。システム ステータスの確認方法の詳細については、「プロセスのリロードに関するトラブルシューティング」を参照してください。

メッセージ:%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 の割合が示されています。システム ステータスの確認方法の詳細については、「プロセスのリロードに関するトラブルシューティング」を参照してください。

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 ホグ状態が持続してノードがリセットされた場合は、シスコのテクニカルサポートにご連絡ください。シスコのテクニカルサポートの連絡窓口についての情報は、「はじめに」「テクニカル サポート」を参照してください。コンソール上またはシステム ログに出力されたエラー メッセージをそのままコピーして、収集した情報とともにテクニカルサポートに提出してください。

プロセスのリロードに関するトラブルシューティング

プロセスのリロードに関するトラブルシューティングを行うには、シスコのテクニカルサポートにご連絡ください。シスコのテクニカルサポートの連絡窓口についての情報は、「はじめに」「テクニカル サポート」を参照してください。

シスコのテクニカルサポートにご連絡いただく前に、次の情報を収集してください。

show context all location all コマンドの出力

show version コマンドの出力

show dll コマンドの出力

show log コマンドの出力

コア ダンプ ファイルを収集します。コア ダンプの収集方法に関する詳細については、「show context コマンド」を参照してください。

プロセス ブロックのトラブルシューティング

プロセス ブロックをトラブルシューティングする手順は、次のとおりです。

手順概要

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
 

RP/0/RP0/CPU0:router# show processes blocked location 0/1/cpu0

show processes blocked コマンドを数回使用し、出力を比較して長時間ブロックされているプロセスがないかどうか確認します。

Name の欄には、ブロックされているプロセス名が表示されます。

Blocked-on 欄には、ブロックされているプロセスの PID が表示されます。

State 欄に Mutex が表示される場合は、プロセス内のスレッドがほかのスレッドを待っています。その場合、Blocked-on 欄には PID ではなく PID と TID が表示されます。

ブロックされているプロセスは、ほかのプロセスによってブロックされることがあります。プロセスが別なプロセスによってブロックされている場合は、ブロッキングのチェーンを追跡し、ブロックしている根源のプロセスを見つける必要があります。ブロッキングのチェーンを追跡するには、ステップ 2 に進みます。

ステップ 2

follow job job-id location node-id
 

RP/0/RP0/CPU0:router# follow job 234 location 0/1/cpu0

他のプロセスをブロックしている根源のプロセスを追跡します。次のコマンドは、プロセスが定期的に実行しているコード部分を示します。

ステップ 3

process restart job-id location node-id
 

RP/0/RP0/CPU0:router# process restart 234 location 0/1/cpu0

プロセスを再起動します。

問題が解決しない場合は、シスコのテクニカルサポートにご連絡ください。シスコのテクニカルサポートの連絡窓口についての情報は、「はじめに」「テクニカル サポート」を参照してください。

シスコのテクニカルサポートが参照しますので、次の情報を収集してください。

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 (ある場合)