Голосовая связь и система унифицированных коммуникаций : Cisco Unified Communications Manager (CallManager)

Аварийный отказ службы Cisco CallManager

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв


Содержание


Введение

Этот документ предоставляет сведения о катастрофическом отказе Сisco CallManager, как определить, испытали ли вы катастрофический отказ, информация, чтобы собрать и предоставить технической поддержке Cisco, и как искать дефекты катастрофического отказа Сisco CallManager, которые существуют.

Предварительные условия

Требования

Для этого документа отсутствуют особые требования.

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Условные обозначения технических терминов Cisco.

Описание аварийного отказа службы Cisco CallManager

Когда Сервис Cisco CallManager (ccm.exe) сбои, вы видите это сообщение в журнале Системного события:

The Cisco CallManager service terminated unexpectedly. 
It has done this 1 time. The following corrective action 
will be taken in 60000 ms. Restart the service.

Другие сообщения, которые вы видите в случае катастрофического отказа:

Timeout 3000 milliseconds waiting for Cisco 
CallManager service to connect. 

The Cisco CallManager failed to start due to the following error. 
The service did not respond to the start or control request in a timely fashion.

В это время, когда устройства как Cisco IP Phone и шлюзы отменяют регистрацию от Сisco CallManager, пользователи испытывают задержанный тональный сигнал готовности к набору номера, и/или Cisco CallManager server замораживается из-за высокой загрузки CPU. См. Журналы событий Сisco CallManager для сообщений журнала регистрации событий, не включенных здесь.

Сервис Cisco CallManager может завершиться катастрофическим отказом из-за одной из этих причин:

  1. Непредвиденное событие происходит в Сервисе Cisco CallManager. Этот катастрофический отказ добавляет запись в журнал Dr.Watson, который существует, и User.dmp генерируется в папке C:\Documents and Settings\All Users\Documents\DrWatson.

  2. Сервис Cisco CallManager не имеет достаточного количества ресурсов как ЦП или память для функционирования. Обычно загрузка ЦПУ в сервере в 100 процентах в то время.

Зависящий от типа аварии вы испытываете, необходимо собрать другие данные, которые помогают вам, и техническая поддержка Cisco определяют основную причину катастрофического отказа.

Определите тип аварии

Если вы выполняете поиск на своем Сisco CallManager после катастрофического отказа для файла под названием Drwtsn32 log и открываете его, посмотрели на большую часть последней записи, чтобы видеть, была ли добавлена запись для ccm.exe. Откройтесь Dr.Watson входят в Блокнот, переходят к нижней части файла и ищут произошедшее Исключение приложения, который берет вас к последнему катастрофическому отказу.

Это - пример заголовка для записи катастрофического отказа в drwtsn32 log.

Application exception occurred:
        App:  (pid=680)
        When: 3/8/2003 @ 14:01:06.978
        Exception number: e06d7363

Рядом с датой катастрофического отказа существует PID, если тот PID соответствует PID для ccm.exe в листе задач тогда, вы знаете, что Сisco CallManager завершился катастрофическим отказом.

Лист задач в drwtsn32 log выглядит подобным этому:

PID  PROCESS
   8 System.exe
 212 SMSS.exe
 240 CSRSS.exe
 264 WINLOGON.exe
 292 SERVICES.exe
 304 LSASS.exe
 424 termsrv.exe
 520 svchost.exe
 560 msdtc.exe
 696 DLLHOST.exe
 736 Ipvmsapp.exe
 752 DLLHOST.exe
 824 AudioTranslator.exe
 848 RisDC.exe
 860 LogoutService.E.exe
 884 DCX500.exe
 936 svchost.exe
 980 LLSSRV.exe
1028 sqlservr.exe
1112 ntpd.exe
1140 rcmdsvc.exe
1172 regsvc.exe
1176 mstask.exe
1204 SNMP.exe
1244 WinMgmt.exe
1260 cpqnimgt.exe
1284 cqmgserv.exe
1296 cqmgstor.exe
1308 sysdown.exe
1372 cqmghost.exe
1524 aupair.exe
1552 sqlagent.exe
 276 svchost.exe
2400 inetinfo.exe
2412 explorer.exe
2752 sqlmangr.exe
2700 taskmgr.exe
2704 mmc.exe
 680 ccm.exe
 868 DRWTSN32.exe

Примечание: В данном примере PID = 680, который из списка, соответствует ccm.exe.

Если нет никакого списка PIDs, посмотрите на метку времени последней записи drwtsn32 log и метку времени ошибки в конечном счете Журнал. Посмотрите раздел Описания Отказа сервиса Cisco CallManager. Если они - то же самое время, вероятно, что вы испытали Непредвиденное событие катастрофический отказ Сisco CallManager.

Трассировка стека делает катастрофический отказ уникальным, который является, почему запрашивают весь файл drwtsn32 log в информации, чтобы Собраться и Предоставить технической поддержке Cisco.

Если PID в течение дня катастрофического отказа не является ccm.exe, или метка времени не соответствует, то вы, скорее всего, столкнулись с отсутствием катастрофического отказа ресурса или катастрофического отказа другого процесса.

Информация, чтобы собраться и предоставить технической поддержке Cisco

Катастрофический отказ непредвиденного события

Если вы испытываете катастрофический отказ Непредвиденного события, выполняете эти шаги для сбора информации для обеспечения технической поддержке Cisco.

  1. Собирайте трассировки программы Cisco CallManager за 15 минут до и через 15 минут после аварийного отказа.

    Трассировки расположены в C:\Program Files\cisco\trace\ccm.

  2. Собирайте трассировки SDL за 15 минут до и через 15 минут после аварийного отказа.

    Трассировки расположены в C:\Program Files\cisco\trace\sdl\ccm.

  3. Выберите Start> Programs> Administrative Tools> Event Viewer для собирания Системных файлов и Файлов регистрации событий приложений от Просмотра событий.

  4. Щелкните по System Log и выберите Action> Save Log как и сохраните журнал.

    Сделайте тот же Журнал приложения.

  5. Проверьте, что параметр SdlMaxUnhandledExceptions имеет значение 0 (нуль) для каждого Cisco CallManager.

  6. Соберите журнал Dr.Watson, расположенный в C:\Documents and Settings\All Users\Documents\DrWatson. Названием файла является Drwtsn32 log.

  7. Соберите файл User.dmp, расположенный в C:\Documents and Settings\All Users\Documents\DrWatson.

    Примечание: Эти файлы могут быть очень большими. Обязательно архивируйте их, прежде чем вы передадите им к технической поддержке Cisco. Также важно обратить внимание, что эти файлы содержат информацию, в которой инженер технической поддержки Cisco и разработчики нуждаются для определения причины катастрофического отказа.

  8. Откройтесь Dr.Watson входят в Блокнот и продолжаются к Определению раздела Типа аварии, чтобы узнать, является ли ваш катастрофический отказ известной неполадкой.

Отсутствие катастрофического отказа ресурса

Если вы испытываете Отсутствие катастрофического отказа Ресурса, выполняете эти шаги для сбора информации для обеспечения технической поддержке Cisco.

  1. Собирайте трассировки программы Cisco CallManager за 15 минут до и через 15 минут после аварийного отказа. Трассировки расположены в C:\Program Files\cisco\trace\ccm.

  2. Собирайте трассировки SDL за 15 минут до и через 15 минут после аварийного отказа. Трассировки расположены в C:\Program Files\cisco\trace\sdl\ccm.

  3. Соберите трассировки perfmon при наличии. Если они не доступны, начните собирать их и использование памяти дорожки и использование ЦПУ для каждого процесса, который работает на сервере. Посмотрите Установленный раздел Журналов Счетчика Монитора производительности для устанавливания трассировок perfmon. Они помогают в случае другого отсутствия катастрофического отказа ресурсов.

Проверьте параметры настройки на программе резервирования для предотвращения высокой загрузки CPU

Гарантируйте выполнение последней Резервной копии Cisco IP Telephony Applications во избежание сбоя системы из-за Резервной копии Cisco IP Telephony Applications, которая может работать для длительного периода времени при высокой загрузке ЦП. Если вы выполняете Сisco CallManager 3.1 (3a) SPC и позже или Cisco Callmanager 3.2 (1) spa и позже, на идентификатор ошибки Cisco CSCdt91655 (только зарегистрированные клиенты), новая Программа резервирования, выполненная в низком приоритете по умолчанию.

Можно загрузить последнюю версию Резервной копии Cisco IP Telephony Applications от ПО для передачи голосовых сообщений страница разгрузки (только зарегистрированные клиенты) под Сisco CallManager.

Примечание: При выполнении просмотра вируса на ПАНЕЛЯХ, организующих каталог C:\STI при выполнении резервной копии можно вызвать Всплески нагрузки ЦПУ. Отключите просмотр вируса на C:\STI во избежание высоких загрузок ЦП.

До этого изменения предыдущие версии использовали вкладку под названием Производительность для изменения Базового приоритета процесса, который выполняет Приложение для резервного копирования Cisco IP Telephony Applications. Измените производительность на ниже обычного или низкого, чтобы гарантировать, что этот процесс не конкурирует с другими процессами, которые работают в обычном базовом приоритете, для ЦП, такого как CCM.exe.

ccmcrash-2.gif

Петли межкластерной маршрутизации могут вызвать скачки высокой загрузки CPU

Цикличное выполнение внутрикластерной магистрали может быть вызвано образцом неправильна настроенного маршрут. Это может заставить Сisco CallManager возрастать ЦП в течение длительного времени времени или катастрофического отказа сервер. Сisco CallManager добавил логику в устройстве H.225 (только для магистрального устройства) для мониторинга количества транзитных вызовов, выдающихся для решения этой проблемы. Транзитный вызов является вызовом, что Сisco CallManager получает запрос настройки для (или передает запрос настройки за), и еще не получает или передает первое обратное сообщение. Например, обработка вызова, ход вызова, предупреждение, подключение или завершенный выпуск. Cisco Call Manager выполняет пяти-секундный таймер для мониторинга очереди транзитного вызова для магистрального устройства H.225. Если количество записей очереди транзитного вызова больше, чем предустановленный порог, то, сроком на время (по умолчанию 30 секунд), весь новый запрос входящего или исходящего вызова к тому магистральному устройству H225 отклонен путем передачи завершенных сообщений выпуска с Перегрузкой Системы коммутации кода причины.

Из-за этого поведения Сisco CallManager, эти ошибки могут быть замечены в журнале приложения Сisco CallManager.

  • Ошибка — сообщение об ошибках ICTCallThrottlingStart указывает, что Сisco CallManager не может обработать призывы к обозначенному устройству H.323 из-за маршрутной петли по транку H.323.

  • Ошибка — сообщение об ошибках ICTCallThrottlingEnd указывает, что Сisco CallManager возобновился, обработка вызова для обозначенного устройства H.323 (остановился из-за маршрутной петли, созданной по транку H.323).

Остановите цикл маршрутизации между кластерами во избежание этих ошибок. См. Руководство Предотвращения Петли Сisco CallManager к Оптимальным методам для получения дополнительной информации о предотвращении Петли Сisco CallManager.

Установите журналы счетчика монитора производительности

Выполните эти шаги для сбора счетчиков для катастрофического отказа для проверки процессов, которые работают и сумма ЦП и памяти, которые использованы.

  1. Выберите Start> Programs> Administrative Tools> Performance.

  2. От Монитора производительности выберите Performance Logs> Alerts> Counter Logs.

  3. Выберите Action> New log settings и введите имя для встречного журнала.

  4. Под счетчиками выберите, добавляют.

    Используйте счетчики локального компьютера и удостоверьтесь, что вы настраиваете это непосредственно на Сisco CallManager, который испытывает катастрофический отказ.

  5. Под Объектом управления выберите Process.

  6. Под Выбирают Counters, выделяют Список>, Выбирают Instances и выбирают эти счетчики и привязанные экземпляры:

    • % Processor Time / All Instances

    • ID процесса / Все экземпляры

    • Виртуальные байты / Все экземпляры

    • Приватные байты / Все экземпляры

  7. Под Типовыми Данными Каждый, устанавливает интервал в 2 и модули как секунды.

  8. Открыв закладку Log Files, убедитесь, что тип файла журнала равен Text File - CSV. Также обратите внимание на их расположение. По умолчанию является C:\PerfLogs.

  9. Выберите максимальный размер файла журнала 20,000 Кбит.

  10. Выполните эти действия из Списка:

    1. Выберите запускают журнал вручную для начала журнала.

    2. Выберите, когда файл журнала на 20,000 Кбит полон для остановки журнала.

    3. Когда журнал закроет, выберите Start новый файл журнала и затем нажмите OK.

  11. Выберите созданный встречный журнал, чтобы начать регистрировать. Затем выберите Action> Start.

    Примечание: В течение долгого времени при включении этих журналов монитора производительности это генерирует большое число файлов и использует большое количество дискового пространства. Поэтому необходимо следить за этим и, если это, на молнии более старые журналы, и/или переместите их от локального устройства.


Дополнительные сведения


Document ID: 19122