音声とユニファイド コミュニケーション : Cisco Unified Communications Manager(CallManager)

Cisco CallManager がクラッシュまたはサービス シャットダウンのどちらによって再起動したかを判別する方法

2014 年 1 月 31 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2010 年 2 月 12 日) | フィードバック

概要

このドキュメントでは、Cisco CallManager のクラッシュとサービス シャットダウンとの違いについて説明します。また、Cisco CallManager のクラッシュを シスコ テクニカル サポートに報告し、問題のトラブルシューティングができるようにする手順についても説明します。

前提条件

要件

このドキュメントに関する固有の要件はありません。

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアのバージョンに基づくものです。

  • Cisco CallManager 3.x および 4.0

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

Cisco CallManager のクラッシュとシャットダウンの違い

クラッシュ

Cisco CallManager のクラッシュは、CallManager のコードのバグが原因で発生します。クラッシュには、主に次の 3 つのタイプがあります。

  • アクセス違反

  • ゼロ除算

  • 不明な例外

クラッシュが発生すると、 ワトソン博士のエントリが作成され、既存の ワトソン博士ファイルの末尾に追加されます。また、クラッシュの際には user.dmp ファイルも作成されます。これらのファイルは、C:\Documents and Settings\All Users\Documents\DrWatson に作成されます。

ワトソン博士ファイルは、drwtsn32.log という名前のテキスト ファイルです。

設定を行うには、[Run] ウィンドウから drwtsn32 を選択します。

ワトソン博士 ファイルの解読方法

ワトソン博士ファイルを解読するには、 次の手順を実行します。

  1. "when"(小文字)という単語を検索し、問題が発生したときの日時を探します。

    ワトソン博士ファイルには、すべてのアプリケーションのクラッシュが記録されるため、 Cisco CallManager のクラッシュではないクラッシュが記録されている場合もあります。Cisco CallManager のクラッシュではないクラッシュの記録には、RisDC.exe や aupair.exe などがあります。

  2. 問題が発生した日時が見つかったら、プロセス識別子(PID)番号を調べ、タスク リストを検索して、クラッシュしたアプリケーションを判別します。

    タスク リストは、この手順の例に表示されています。

    下の例では、クラッシュしたアプリケーションの PID は 752 で、アプリケーション名は SCAN32.exe です。

    Application exception occurred:
            App:  (pid=752)
            When: 9/1/2000 @ 10:23:40.836
            Exception number: c0000005 (access violation)
    
    *----> System Information <----*
            Computer Name: CISCO-8VCUWBLUJ
            User Name: SYSTEM
            Number of Processors: 1
            Processor Type: x86 Family 6 Model 8 Stepping 3
            Windows 2000 Version: 5.0
            Current Build: 2195
            Service Pack: None
            Current Type: Uniprocessor Free
            Registered Organization: Cisco Systems Inc.
            Registered Owner: Cisco User
    
    *----> Task List <----*
       0 Idle.exe
       8 System.exe
     144 smss.exe
     168 csrss.exe
     164 winlogon.exe
     216 services.exe
     228 lsass.exe
     336 ibmpmsvc.exe
     380 svchost.exe
     424 svchost.exe
     576 regsvc.exe
     592 MSTask.exe
     924 Explorer.exe
     992 cmd.exe
     972 msiexec.exe
     928 tp4mon.exe
     856 ibmpmsvc.exe
     852 ltmsg.exe
     408 RunDll32.exe
     428 RunDll32.exe
     328 PDirect.exe
     620 TP98.exe
     968 tphkmgr.exe
     948 PRPCUI.exe
     668 AUTOCHK.exe
     744 tponscr.exe
     868 KIX32.exe
     520 spoolsv.exe
    1164 Avsynmgr.exe
    1136 VsStat.exe
    1192 Vshwin32.exe
    1224 Mcshield.exe
    1024 MCUPDATE.exe
    752 SCAN32.exe
    1292 drwtsn32.exe
       0 _Total.exe
  3. クラッシュしたアプリケーションが Cisco CallManager の場合は、例外番号からクラッシュのタイプを判別します。

    注:Cisco CallManager 以外のアプリケーションのクラッシュの場合は、該当する開発チームに問い合わせてください。

    Application exception occurred:
    
            App:  (pid=752)
    
            When: 9/1/2000 @ 10:23:40.836
    
            Exception number: c0000005 (access violation)
    

    この例では、例外番号は c0000005で、これは アクセス違反です。この アクセス違反 は、オペレーティング システムによって設定されたアプリケーション メモリの範囲外の領域にアプリケーションがアクセスしようとしたことを意味します。

    他に考えられるクラッシュのタイプはゼロ除算です。次の例に示すように、ゼロ除算の例外番号は c0000094です。

    Application exception occurred:
    
            App:  (pid=1564)
    
            When: 1/7/2003 @ 13:16:15.051
    
            Exception number: c0000094 (divide by zero)
    

    クラッシュ タイプには不明な例外もあります。次の例に示すように、不明な例外の例外番号は e06d7363です。

    Application exception occurred:
    
            App:  (pid=2784)
    
            When: 12/10/2002 @ 09:02:58.202
    
            Exception number: e06d7363
    

    クラッシュの原因がアクセス違反なのか、ゼロ除算、または不明な例外なのかを判別したら、既存の Cisco bug とクラッシュを照合できます。適合する Cisco bug がない場合は、何が発生したのかを特定する手がかりを開発エンジニアに問い合わせます。

  4. ファイルの when セクションの下で FAULT という単語を探し、クラッシュの「シグニチャ」を定義します。

    注:  FAULT は大文字で表示されます。

    ファイルの FAULT セクションには、次の 6 つの重要な情報が含まれています。

    • 問題が生じたスレッドの番号

    • クラッシュ発生時のこのスレッドのレジスタの内容

    • クラッシュ発生時に実行されていた関数

    • クラッシュによって生成されたアセンブリ コード ステートメント

    • クラッシュの発生直前に実行されていた関数のアドレスを順に示すスタック バック トレース

    • クラッシュ発生時のランタイム スタックの内容に関する詳細情報を示す、ロウ スタック ダンプ

    次に示すコードは、アクセス違反による Cisco CallManager のクラッシュの例を示しています。太字で強調表示しているのは、上記の 6 つの重要な要素と FAULTという単語です。この単語がファイル内のこのセクションのマーカーです。

    State Dump for Thread Id 0x998
    
    !--- This number is the number of the thread that experienced the problem.
    
    
    eax=00cae82c ebx=02070000 ecx=00e95da0 edx=346984d8 esi=34698970 edi=346984d8
    eip=77fcb9b3 esp=05cef34c ebp=05cef358 iopl=0         nv up ei ng nz na pe cy
    cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000283
    
    !--- This provides the contents of the registers at the time of the crash.
    
    function: RtlSizeHeap
    
    !--- This function executed at the time of the crash.
    
            77fcb992 0f87aafeffff     jnbe    RtlFreeHeap+0x20f (77fcb842)
            77fcb998 807d1400         cmp     byte ptr [ebp+0x14],0x0      ss:
             0650c92a=??
            77fcb99c 0f8586300000     jne     RtlZeroHeap+0x327 (77fcea28)
            77fcb9a2 57               push    edi
            77fcb9a3 53               push    ebx
            77fcb9a4 e8646cfbff       call RtlConsoleMultiByteToUnicodeN+0x348 
             (77f8260d)
            77fcb9a9 8b4f0c           mov     ecx,[edi+0xc]          ds:
             34eb5aaa=00003781
            77fcb9ac 8b4708           mov     eax,[edi+0x8]          ds:
             34eb5aaa=00003781
            77fcb9af 3bc1             cmp     eax,ecx
            77fcb9b1 8901             mov     [ecx],eax              ds:
             00e95da0=00cae82c
    FAULT ->77fcb9b3 894804           mov     [eax+0x4],ecx          ds:
     014cbdfe=ec810000
    
    
    !--- This is the assembly code statement that resulted in the crash.
    
    
            77fcb9b6 744d             jz      77fd4405
            77fcb9b8 8a4705           mov     al,[edi+0x5]                 ds:
             34eb5aaa=81
            77fcb9bb a804             test    al,0x4
            77fcb9bd 0f8521310000     jne     RtlZeroHeap+0x3e3 (77fceae4)
            77fcb9c3 8a4605           mov     al,[esi+0x5]                 ds:
             34eb5f42=d5
            77fcb9c6 2410             and     al,0x10
            77fcb9c8 a810             test    al,0x10
            77fcb9ca 884705           mov     [edi+0x5],al                 ds:
             34eb5aaa=81
            77fcb9cd 0f8555030000     jne     RtlSizeHeap+0x3ef (77fcbd28)
            77fcb9d3 0fb70f           movzx   ecx,word ptr [edi]         ds:
             346984d8=0093
            77fcb9d6 8b4510           mov     eax,[ebp+0x10]         ss:
             0650c92a=????????
    
    *----> Stack Back Trace <----*
    
    !--- This shows, in order, the addresses of the functions that executed
    !--- just before the crash.
    
    FramePtr ReturnAd Param#1  Param#2  Param#3  Param#4  Function Name
    05CEF358 77FCB733 02070000 34698970 05CEF3D0 00000000 ntdll!RtlSizeHeap 
    05CEF400 7800115C 02070000 00000000 34698978 05CEF454 ntdll!RtlFreeHeap 
    05CEF448 00C0304F 34698978 00545EC2 34698978 34698978 !free 
    05CEF460 00B66F85 00000001 00B6626C 033B3D58 025A6720 !<nosymbols> 
    05CEFF34 018E736B 025A6720 77E964CB 033C6B20 033C6B20 !<nosymbols> 
    05CEFF80 780060CE 033B3D58 77E964CB 00000018 033C6B20 !ACE_OS_Thread_Adapter::
     invoke
    ƒÊƒÊ
    05CEFFEC 00000000 00000000 00000000 00000000 00000000 kernel32!TlsSetValue 
    
    *----> Raw Stack Dump <----*
    
    
    !--- This provides more information about what was on the run-time stack
    !--- at the time of the crash.
    
    05cef34c  00 00 07 02 70 89 69 34 - 00 00 00 00 00 f4 ce 05  ....p.i4........
    05cef35c  33 b7 fc 77 00 00 07 02 - 70 89 69 34 d0 f3 ce 05  3..w....p.i4....
    05cef36c  00 00 00 00 54 f4 ce 05 - 78 89 69 34 20 67 5a 02  ....T...x.i4 gZ.
    05cef37c  44 5b e3 09 94 f3 ce 05 - 30 e6 b5 00 fc f3 ce 05  D[......0.......
    05cef38c  38 29 6a 09 40 5b e3 09 - a8 f3 ce 05 65 e5 b5 00  8)j.@[......e...
    05cef39c  fc f3 ce 05 38 29 6a 09 - 40 5b e3 09 c4 f3 ce 05  ....8)j.@[......
    05cef3ac  39 e2 b5 00 57 92 89 01 - 30 db 55 02 f5 50 5b 00  9...W...0.U..P[.
    05cef3bc  e0 f3 ce 05 cc f3 ce 05 - 0f 4f 5b 00 e0 f3 ce 05  .........O[.....
    05cef3cc  00 00 07 02 19 00 00 00 - 01 f4 ce 05 f8 2b cf 21  .............+.!
    05cef3dc  f8 2b cf 21 01 f1 ce 05 - 28 ff ce 05 70 f3 ce 05  .+.!....(...p...
    05cef3ec  98 ef ce 05 38 f4 ce 05 - a7 9d fb 77 90 26 f8 77  ....8......w.&.w
    05cef3fc  01 00 00 00 48 f4 ce 05 - 5c 11 00 78 00 00 07 02  ....H...\..x....
    05cef40c  00 00 00 00 78 89 69 34 - 54 f4 ce 05 04 fa ce 05  ....x.i4T.......
    05cef41c  20 67 5a 02 02 00 00 00 - 64 00 00 00 5c 00 00 00   gZ.....d...\...
    05cef42c  fe 08 00 00 00 00 00 00 - 98 ef ce 05 28 ff ce 05  ............(...
    05cef43c  b8 ff 00 78 50 32 03 78 - ff ff ff ff 60 f4 ce 05  ...xP2.x....`...
    05cef44c  4f 30 c0 00 78 89 69 34 - c2 5e 54 00 78 89 69 34  O0..x.i4.^T.x.i4
    05cef45c  78 89 69 34 34 ff ce 05 - 85 6f b6 00 01 00 00 00  x.i44....o......
    05cef46c  6c 62 b6 00 58 3d 3b 03 - 20 67 5a 02 98 f6 e6 36  lb..X=;. gZ....6
    05cef47c  98 f6 e6 36 00 00 00 00 - 00 00 00 00 00 00 00 00  ...6............
    

    これらの 6 つの情報は、クラッシュのシグニチャの一部(全部ではありません)を構成しています。シグニチャを定義する残りの情報は次のとおりです。

    • クラッシュのタイプ(アクセス違反、ゼロ除算、または不明な例外)

    • クラッシュの直前に実行されていた最後の Signal Distribution Layer(SDL)トレース ステートメント

      注:クラッシュの前に使用されていた最後の SDL ファイルには、 ワトソン博士ファイルと同様に、あらゆるクラッシュ バグが追加されています。

    このシグニチャ情報(直前の SDL ファイル、直前の Cisco CallManager ファイル、および ワトソン博士ファイル)は、新しいクラッシュ Distributed Defect Tracking System(DDTS)ファイルを作成すると、DDTS レコードに追加されます。

    新しいクラッシュと既存の DDTS とが一致し、根本原因が同じであれば、次の情報は同じです。

    • 例外のタイプ

    • クラッシュ発生時に実行されていた関数の名前

    • スタック バック トレースの中の関数名

      注:これらの名前は、 ワトソン博士ファイルには表示されない場合もあります。

    • FAULT マーカーの横に表示されるアセンブリ コード ステートメント

    • 最後の SDL トレース行(きわめて類似しているはずです)

    クラッシュの原因が既存の DDTS と同じ場合でも、レジスタの内容、メモリ アドレス、および他の情報は異なる場合があります。実行している Cisco CallManager のバージョンが異なればアドレスも変わります。実行している Cisco CallManager のバージョンが同じであれば、アセンブリ コード セクションおよびスタック トレース セクションに表示されるアドレスは同じです。

  5. クラッシュをデバッグするために、次のファイルを収集します。

    • drwtsn32.log

    • user.dmp

    • 直前の SDL トレース ファイルと Cisco CallManager トレース ファイル(クラッシュの前の約 5 分間と、再始動後の約 5 分間)

    • proglog ファイル

      注:このファイルは、Cisco CallManager バージョン 3.2 以降を使用している場合のみ収集してください。

    • システムとアプリケーションの両方のイベント ログ(存在する場合)

    • パフォーマンス モニタ(perfmon)のログ(存在する場合)

DBLException エラー

このエラー メッセージは、Cisco CallManager パブリッシャとサブスクライバの両方のアプリケーション ログに表示されます。

Error: DBLException - DBL Exception.
  ErrorCode: 8
  ExceptionString: Invalid parameter
  UNKNOWN_PARAMNAME:Text: addDevice
  App ID: Cisco CallManager
  Cluster ID: XXXX-Cluster
  Node ID: 192.168.0.2
Explanation: Severe database layer interface error occurred.
Recommended Action: Contact TAC.. 

または

A COM error occurred during processing. (6)

Details:
Error No. -2147219962 (0x80040606):
CDBLException Dump: [COM Error] COM Error Description = []

このタイプのエラーが発生するのは、IP フォンが登録拒否された場合か、パブリッシャ データベースとサブスクライバ データベースの間のサブスクリプションが壊れている場合です。この問題は DBLHelper ツールを使用して解決できます。DBLHelper の詳細は、『Cisco CallManager クラスタでの切断された SQL サブスクリプションの DBLHelper を使用した再構築』を参照してください。

このエラーは、Cisco Database Layer Monitor サービスがクラッシュしたときにも発生します。この問題を解決するには、次の手順を実行します。

  1. [Start] > [Programs] > [Administrative Tools] > [Component Services] の順に選択します。

  2. [Component Services] > [Computers] > [My Computer] > [COM+ Applications] の順に展開します。

  3. MSDTC(分散トランザクション コーディネーター)サービスを起動します(停止している場合)。

シャットダウン

Cisco CallManager の再始動のもう一つのタイプは、シャットダウンです。これは、CallManager が実質的に動作できなくなり、自身をシャットダウンするものです。シャットダウンは次の 2 つのカテゴリに分かれます。

Cisco CallManager が自身をシャットダウンすると、CallManager のトレースの最後の数行にシャットダウンの Reason code が表示されます。次に例を示します。

03/22/2003 14:32:16.562 Cisco CallManager|CallManagerFailure - Indicates
some failure in the Cisco CallManager system. Host name of hosting
node.:NEROCM1 IP address of hosting node.:172.27.27.224 Reason code.:4
Additional Text [Optional]: App ID:Cisco CallManager Cluster
ID:NEROCM1-Cluster Node
ID:172.27.27.224|<CLID::NEROCM1-Cluster><NID::172.27.27.224><CT::Alarm>

次の例では、理由コードが 4になっています。次に示しているのは、Cisco CallManager のコードに含まれるシャットダウンの理由コードです。

class CallManagerFailureAlarm : public CallManagerAlarmCatalog {
public:
            enum Reason {
                        Unknown = 1,
                        HeartBeatStopped = 2,
                        RouterThreadDied =3 ,
                        TimerThreadDied = 4,
                        CriticalThreadDied = 5,
                        DeviceMgrInitFailed = 6,
                        DigitAnalysisInitFailed = 7,
                        CallControlInitFailed = 8,
                        LinkMgrInitFailed = 9,
                        DbMgrInitFailed = 10,
                        MsgTranslationInitFailed = 11,
                        SupServiceInitFailed = 12,
                        DirectoryInitFailed = 13
            };

理由 1 と理由 2 は内部シャットダウンの珍しいケースですが、他の理由は一般的なものです。理由 3 は、SDL ルータ スレッドから応答がなくなったことを示します。理由 4 は、SDL タイマー スレッドから応答がなくなったことを示します。理由 5 〜 13 は、初期化タイマーのタイムアウトと関連しています。

初期化タイムアウト

Cisco CallManager サービスを初めて開始したときに CallManager Process Monitor(CMProcMon)スレッドが起動します。その後、MmmanInit スレッドが起動し、これによって他のすべてのプロセスが生成されます。次に SDL ルータ スレッドが起動します。このスレッドは、あるプロセスから他のプロセスへ送信されたシグナルを処理します。これら 3 つのスレッドはすべて同時に起動します。MmmanInit スレッドが他のプロセスを起動させる際には、CMProcMon スレッドと SDL ルータ スレッドが起動して実行中である必要があります。

MmmanInit スレッドがさまざまなプロセスを起動している間、CMProcMon と SDL が起動して実行中である必要があります。MmmanInit スレッドは、次のプロセスを次の順序で起動します。

  1. データベース(ProcessDb)

    注:ProcessDb は Cisco CallManager のデータベース層(DBL)のコードに対するインターフェイスです。

    MmmanInit のコードは、同時に CallManager 内部の独立した他のプロセスを複数起動します。起動されるプロセスには、H225Handler、MGCPBhHandler、LineManager などがあります。

  2. リージョン

  3. AARNeighborhood

  4. ロケーション

  5. ルート計画

  6. ディジット分析

  7. コール制御

  8. 補足サービス

    コール パーク、自動転送、会議、転送などの機能が含まれます。

  9. デバイス

  10. ディレクトリ

  11. Calling Search Space Manager(CSSManager)

  12. Time of Day Manager(TODManager)

これらのタスクは連続して実行されます。この 12 のタスクにはそれぞれタイマーがあり、 タイマーはタスクの起動時に開始されます。タスクが完了する前にタイマーが切れると、Cisco CallManager は停止し、次のような SDL トレースが出力されます。

Critical thread death: name of the timer which fired

このリストには、各タイマーと、そのタイマーを開始する SDL シグナル、およびタイマーを停止する SDL シグナルが表示されます。SDL トレースに "InitDone" シグナルが表示されるようにするには、トレース レベルを適切に設定する必要があります (SdlTraceTypeFlags を 0x8000CB15 に設定します)。

次に示すデフォルト タイマーは Cisco CallManager バージョン 4.1(2) に基づいています。実行しているバージョンが異なる場合は、値がわずかに異なる可能性があります。

  1. データベースの初期化時間(デフォルトは 900 秒):このタイマーを開始するシグナルは、MmmanInit プロセスに送られる "start" シグナルです。このシグナルは SDL トレースに書き込まれます。

  2. リージョンの初期化時間(デフォルトは 120 秒)

  3. AARNeighborhoods の初期化時間(デフォルトは 90 秒)

  4. ロケーションの初期化時間(デフォルトは 90 秒)

  5. ルート計画の初期化時間(デフォルトは 600 秒)

  6. ディジット分析の初期化時間(デフォルトは 900 秒)。

  7. コール制御の初期化時間(デフォルトは 90 秒)

  8. 補足サービスの初期化時間(デフォルトは 900 秒):開始シグナルは CcInitDone で停止シグナルは SsInitDone です。

  9. デバイスの初期化時間(デフォルトは 360 秒)

  10. ディレクトリの初期化時間(デフォルトは 90 秒)

  11. CSSManager の初期化時間(デフォルトは 900 秒)

  12. TODManager の初期化時間(デフォルトは 900 秒)

すべてのタスクが完了すると、Cisco CallManager はネットワーク上の他のノードで実行されている CallManager サービスへの SDL リンクを開きます。ネットワーク上の同じノードや別のノードで稼働しているコンピュータテレフォニーインテグレーション(CTI)マネージャ サービスへの SDL リンクも開きます。

次に、MmmanInit が CMInitComplete シグナルを CMProcMon スレッドへ返信します。CMProcMon を初めて起動すると、Cisco CallManager を初期化するために、60 分にハードコードされたタイマーが開始されます。タイマーの名前は CMInitComplete_WaitTime です (これはサービス パラメータではありません。また、設定変更はできません)。CMProcMon スレッドが CMInitComplete シグナルを 60 分以内に受信しなかった場合は CallManager が停止し、次のようなトレース ステートメントが出力されます。

Timed out waiting for CMInitComplete signal

12 の初期化タスクのいずれかが失敗するか、これらのタスクの合計処理時間が 60 分を超過すると、CallManager は停止します。

注:CMInitComplete_WaitTime タイマーはかつて 10 分にハードコードされていましたが、 Cisco bug ID CSCdx31622登録ユーザ専用)への対応の一環で 60 分に変更されました。この変更は、3.1(3) Engineering Special(ES)トレインの ES 38 から、 そして、3.2(2) ES トレインでは ES 11 から適用されています。また、Cisco CallManager 3.3 にも適用されています。

初期化タイマーが切れるという問題がある場合は、タイマーの設定値を増やすだけで起動の問題が解決することもあります。変更しても解決しない場合は、データベースの応答所要時間が長いために処理がタイムアウトしている可能性があります。その場合は、SDL トレースおよび Cisco CallManager トレースの他に、必要に応じて詳細な DBL トレースを収集してください。

初期化の問題をデバッグするには、次のファイルを収集します。

  • 詳細な Cisco CallManager トレース

  • SDL トレース

    注:SdlTraceTypeFlags を 0x8000CB15 に設定してください。

  • 詳細な DBL トレース

SDL タイマーと SDL ルータ スレッドの停止

SDL ルータ スレッドは、Cisco CallManager アプリケーション内で実行されるスレッドの中で最も重要なスレッドです。呼処理シグナルの送信を制御しているのがこのスレッドです。CMProcMon スレッドは、SDL ルータ スレッドの状態を 2 秒ごとに確認します。これは Cisco CallManager のトレースに次のように表示されます。

02/05/2003 00:30:32.790 Cisco CallManager|CMProcMon - ------Entered Router 
Verification|<CLID::USNYTSVOIPPB01-Cluster><NID::10.2.40.11>

02/05/2003 00:30:32.790 Cisco CallManager|CMProcMon - ----Exited Router 
Verification|<CLID::USNYTSVOIPPB01-Cluster><NID::10.2.40.11>

CMProcMon スレッドがルータの検証を開始して終了すれば、SDL ルータ スレッドがヘルス チェックに応答したことになり、正常であると判断されます。

しかし、SDL ルータ スレッドが応答しない場合は、次に示すように、Cisco CallManager のトレースに While loop と出力されます。

CMProcMon - ----Entered While loop ++++ TimeAtWhileEntry: [some number here], 
TimeBeforeSleep: [another number], TimeAfterSleep: [a third number], sleepTimeWas : 
[4th number"

このような緊急事態には、20 秒間にわたって SDL ルータ スレッドの状態が 1 秒ごとに確認されます。この 20 秒の間に何らかの応答があった場合は、通常の処理が再開され、SDL ルータ スレッドの状態は再度 2 秒ごとに確認されるようになります。ただし、この 20 秒間に SDL ルータ スレッドから応答がなかった場合は、Cisco CallManager アプリケーションはシャットダウンし、 SDL トレースに次のようなステートメントが出力されます。

000177508| 01/12/31 07:28:40.389| 001| AlarmErr  |    
 |                  |                  |                  |              
| AlarmClass: CallManager, AlarmName: CallManagerFailure, AlarmSeverity: Error 
AlarmMessage: , AlarmDescription: Indicates some failure in the Cisco CallManager 
 system., 
AlarmParameters:  HostName:CCM-PUB, IPAddress:10.5.162.180, Reason:3, Text:, 
AppID:Cisco CallManager, ClusterID:CCM-PUB-Cluster, NodeID:10.5.162.180,

このトレース ステートメントのテキストには、理由コードとして 3 が表示されています。このコードは、SDL ルータ スレッドが応答を停止したために Cisco CallManager がシャットダウンしたことを意味しています。

SDL ルータ スレッドがシャットダウンする原因として最も可能性が高いのは、システムのリソース不足です。他のアプリケーションが長時間(20 秒以上)にわたって CPU のほとんど、またはすべてを使用していました。このようなタイプのシャットダウンのデバッグにはパフォーマンス モニタが必須となるのはそのためです。

調査が必要な他のタイプのシャットダウンとしては、SDL タイマー スレッドのシャットダウンがあります。SDL タイマー スレッドのシャットダウンが発生するのは、Cisco CallManager の内部クロックと外部のオペレーティング システム クロックとの差が 16 秒を超えたときです。この現象が発生すると、Cisco CallManager のトレースに次のトレース情報が表示されます。

03/22/2003 14:32:16.562 Cisco CallManager|CallManagerFailure - Indicates
some failure in the Cisco CallManager system. Host name of hosting
node.:NEROCM1 IP address of hosting node.:172.27.27.224 Reason code.:4
Additional Text [Optional]: App ID:Cisco CallManager Cluster
ID:NEROCM1-Cluster Node
ID:172.27.27.224|<CLID::NEROCM1-Cluster><NID::172.27.27.224><CT::Alarm>

Cisco CallManager は通常、タイマー スレッドを 1 秒ごとに確認します。オペレーティング システムの現在の時刻に 1 秒を加え、その値を「予測時刻」として保存した後、1 秒間スリープ状態になります。スリープ状態が終わった後、オペレーティング システムの新しい時刻を確認し、予測時刻を差し引きます。この 2 つの時刻の差が 1 秒を超えると、Cisco CallManager のトレースに次の警告ステートメントが表示されます。

CMProcMon::star_sdlVerification - Test Timer exceeded minimum timer latency 
threshold of  1000 milliseconds, Actual latency: 1630 milliseconds

このステートメントに含まれる Actual latency は、Cisco CallManager 内部の SDL タイマー スレッドの実行が遅いことを意味します。ここでは、Cisco CallManager の予測時刻とオペレーティング システムの実際の時刻の差が 1.63 秒になっています。

この差が 16 秒を超えると、Cisco CallManager はシャットダウンし、シャットダウンの理由コード 4が表示されます。

SDL タイマー スレッドがシャットダウンする原因として最も可能性が高いのは、Cisco CallManager が使用できる CPU 時間の不足です。VirusScan や STI Backup などの他のアプリケーションが、16 秒以上にわたって CPU リソースのほとんどを使用していました。Perfmon ログは、このタイプのシャットダウンの原因を判別するために必須です。

Cisco IP テレフォニー アプリケーション バックアップが長時間にわたって CPU 使用率が高い状態で稼働していると、システム クラッシュが発生する可能性があります。このシステム クラッシュを回避する方法についての詳細は、

SDL ルータ スレッドまたは SDL タイマー スレッドがシャットダウンした場合は、次のファイルを収集してください。

  • 詳細な Cisco CallManager トレース

  • SDL トレース

    注:SdlTraceTypeFlags を 0x8000CB15 に設定してください。

  • システム上で実行されていたすべてのプロセスの CPU 使用率を示す perfmon トレース(取得してある場合)

    注:これらのトレースは、Cisco CallManager を実行するサーバの CPU パフォーマンスへの影響を減らすために、リモートから取得することもできます。

Cisco CallManager のクラッシュをシスコ テクニカル サポートに報告する方法

Cisco CallManager のクラッシュの真の原因を診断するのは困難です。原因を突き止めて迅速に解決するために、 シスコ テクニカル サポートでは、必ずトレースと ワトソン博士のログを収集して情報を シスコ テクニカル サポートのケース ノートへアップロードしていただくことをお願いしています。ケース ノートは attach@cisco.com 宛てに送信してください。このとき、メールの件名にケース番号を添えてください。手順は次のとおりです。

  1. クラッシュの 30 分前から 15 分後までの Cisco CallManager トレース ファイルを収集します。

    このトレースは、C:\Program Files\Cisco\Trace\CCM にあります。

  2. クラッシュの 30 分前から 15 分後までの SDL トレース ファイルを収集します。

    このトレースは、C:\Program Files\Cisco\Trace\SDL\CCM にあります。

  3. user.dmp ファイルと drwtsn32.log ファイルを収集します。

    これらのファイルは、C:\Documents and Settings\All Users\Documents\DrWatson に作成されます。

  4. [Start] > [Programs] > [Administrative Tools] > [Event Viewer] の順に選択して、イベント ビューアからシステムとアプリケーションのイベント ログ ファイルを収集します。

    イベント ログ データが不要な場合は、この手順を省略できます。ただし、システムとアプリケーションのイベントをダンプし、クラッシュの前の約 30 分間のイベントだけを抽出します。これらのイベントを調査してから シスコ テクニカル サポートに送信してください。より重要なイベントが見つかる可能性があります。

    注意 注意:イベント ビューア(Microsoft の組み込みユーティリティ)を使用してこれらのイベントをテキスト ファイルにダンプする場合は注意が必要です。CPU 使用率の高いシステムでは、このようにイベント ビューアを使用すると、他のすべてのプロセスがすぐに CPU 不足になる可能性があります。対象となるプロセスには、電話の登録を管理する CallManager KeepAlive プロセスも含まれます。

    個々のログに含まれるすべてのエントリは、elogdmp.exe という名前のシェアウェア ユーティリティを使用してテキスト ファイルにダンプすることができます。elogdmp.exe ツールを使用する際の CPU への影響は、ほとんどありません。DOS プロンプトから、次のコマンドを発行します。

    elogdmp COMPUTER_NAME Application > AppEvents.txt
    
    elogdmp COMPUTER_NAME System > SysEvents.txt
    
  5. すべてのファイルを次に示す順序で zip ファイルに圧縮してから、メールで送信してコピーしてください。

    ファイルの圧縮には、WinZip バージョン 8 を使用してください (Cisco はこのユーティリティのサイト ライセンスを所有しています)。通常は、より迅速に評価できるように、ローカル マシンにファイルをコピーします。圧縮されたファイルは容量が小さく、元のファイル形式よりも短い時間で移動できます。

    1. user.dmp ファイルと drwtsn32.log ファイルを一緒に圧縮します。

      すぐにこの zip ファイルを送信し、コピーします。症状の説明と、Cisco CallManager の正確なバージョン、当該デバイスの負荷、および Cisco IOSR ソフトウェア バージョンをお知らせください。特別なパッチを使用している場合は、そのことについても明確に伝えてください。

    2. Cisco CallManager のトレース ファイルと SDL のトレース ファイルを一緒に圧縮します。

      この zip ファイルを送信およびコピーし、連絡があるまで保存しておいてください。

    3. perfmon ログをまとめて圧縮します。

      この zip ファイルを送信およびコピーし、連絡があるまで保存しておいてください。

    4. イベント ログのエントリをまとめて圧縮します。

      この zip ファイルを送信およびコピーし、連絡があるまで保存しておいてください。

  6. すべてのトレースとログを収集したら、これらのファイルを圧縮し、その zip ファイルを attach@cisco.com 宛てに送信してください。メールの件名にはケース番号を添えてください。

関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 46806