Голосовая связь и система унифицированных коммуникаций : Cisco Unity

Диагностика проблем Domino Unified Communication Services (DUCS)

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


Содержание


Введение

Этот документ обсуждает, как диагностировать проблемы с Cisco Domino Unified Communication Services (DUCS). Этот документ также обсуждает связанные проблемы уведомления, (DUC) завершается катастрофическим отказом/"зависает", и проблемы производительности.

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

Требования

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

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

Сведения, содержащиеся в данном документе, касаются следующих версий программного и аппаратного обеспечения:

  • Cisco Unity 4. x

  • Cisco Unity 5. x

  • Cisco Unity 7. x

  • Cisco Unity 8. x

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

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

Диагностика неисправности

Для диагностирования проблем с DUCS необходимо включить отслеживание DUC и включить вход через консоль если не уже включенный. Затем, соберите console.log/log.nsf файлы, которые охватывают время от того, когда Сервер Domino запустился к тому, когда происходит проблематичная проблема. Если вы диагностируете сбои, "зависает", и проблемы производительности, также необходимо передать Системную диагностику примечаний (NSD). NSD производит файл журнала, который автоматически генерируется в случае катастрофического отказа сервера и сохранен в data\IBM_TECHNICAL_SUPPORT каталоге в каталоге установки Domino.

Примечание: Cisco Unity хранит голосовые сообщения в пользовательской базе данных файла почты по Серверу Domino. Если Domino установлен на одном или более серверах (никогда на сервере Cisco Unity), у всех абонентов должны быть свои почтовые ящики Domino на других серверах. Каждый Сервер Domino, который помещает Абонентов Cisco Unity, должен иметь Унифицированную связь IBM Lotus Domino для установленного Cisco.

Включите Подробные сведения Console.log/Log.nsf

Удостоверьтесь, что установили UCLogLevel сначала в notes.ini файле.

0 - No logging (This is the same as having no UCLogLevel entry)
1 - Minimal logging - only Fatal and Error events are logged
2 - Normal logging - Fatal, Error and Warning events are logged
3 - Informational logging - Fatal, Error, Warning and Informational events are logged.
4 - Verbose logging - Fatal, Error, Warning, Informational and Verbose events are logged.

По умолчанию равняется 1, но 4 рекомендуется для диагностирования проблем.

Включите отслеживание DUC

Отслеживание DUC позволяет вам видеть пути выполнения кода, которые проходит через DUC. Отслеживание DUC трудно понять, не имея исходного кода. Однако вы видите основной поток функций, таких как уведомления, которые созданы. Ищите сообщения об ошибках, которые могли бы присутствовать.

Установите эти notes.ini переменные:

trace_uc_all=1
trace_uc_dir=<output files dir> (W32 only)

Сервер Domino должен быть перезапущен для изменений в ini переменных для имения место. Примите во внимание название/имя файла пользователя тестирования и остановите Сервер Domino, когда вы захотите собрать файлы.

Соберите .out файлы

Если вы не уверены в том, какой .out файлы собрать, передайте им всем. Однако проверьте, что .out файлы, которые вы собираете, от корректного промежутка времени.

Вот является некоторый тип проблемы в качестве примера / именами файлов, которые могли бы генерироваться:

  • Ошибки, позволяющие/запрещающие пользователям (передают ucadminp выходные файлы),

  • MWI не включает во время доставки сообщения (маршрутизатор, ucevent, csumhlr, ucxmlextend)

  • MWI не выключает на открытом сообщении (сервер, ucevent, csumhlr, ucxmlextend)

  • Сервер завершается катастрофическим отказом/"зависает" (передайте все выходные файлы),

NSD для Завершаться катастрофическим отказом/"зависать"/Проблемы производительности

NSDs берут снимок содержания, найденного в памяти о процессе примечаний/Domino. NSDs может показать, какие процессы вызвали катастрофический отказ, или "зависнуть". NSDs должен стрелять автоматически в случае катастрофического отказа, но для проблем производительности или "зависает", ручное вмешательство требуется.

Анализ NSD

Часто, первый шаг, сделанный для решения катастрофического отказа сервера, должен определить процесс, который завершился катастрофическим отказом сервер. В Domino 6 и позже, файл NSD может быть отличным местом для начала. NSD дает вам всем текущую информацию о состоянии сервера, такого как стеки вызовов для всех потоков, данных памяти, и т.д. В случае катастрофического отказа файл журнала NSD автоматически генерируется Сервером Domino и сохранен в data\IBM_TECHNICAL_SUPPORT каталоге. Журнал NSD будет иметь имя файла со штампом времени, который показывает время, когда генерировался NSD. Например, Nsd_W32I_KIRANTP_2006_01_17@17_17_18.log указывает, что этот NSD был создан 17 января 2006. Когда NSD выполняется, он подключает к каждому процессу и потоку для формирования дампа стеков вызовов. Это может помочь вам определять причину катастрофического отказа рабочей станции или сервера.

Основа файла NSD является разделом трассировки стека. Этот раздел предоставляет отказ пути выполнения кода каждого потока в существующем процессе, пересеченном для помещения его в его текущее состояние. Это полезно для исследования, "зависают" или завершаются катастрофическим отказом ситуации на сервере. Кроме того, путем исследования файла NSD вы можете найти любые ключевые файлы генерируемыми в каталоге данных Domino и можете выполнить анализ опорного уровня для отслеживания заключительного стека вызовов, которые были выполнены процессом, который умер и оставил позади ядро. В сложном продукте, таком как Domino, трассировка стека того же типа действия на двух других серверах может привести к другим результатам.

В файле NSD можно выполнить поиск слова "фатального", "панического", или "сегментация" для определения исполняемого файла в процессе сбоя. Путем обнаружения процесса вы видите то, что предшествовало ему, и, надо надеяться, определите, как произошел катастрофический отказ. Когда никакое "паническое" или "фатальное" не будут найдены, иногда дамп основной памяти будет содержать ссылку на "отказ сегментации" в функции. Это указывает, что процесс попытался обратиться к сегменту совместно используемой памяти, который был поврежден по некоторым причинам и завершится катастрофическим отказом, не вызывая "фатальную ошибку" или "панику".

Это - типовая выборка от файла NSD, где процесс сервера вовлечен в катастрофический отказ:

--------------------------------------------
### FATAL THREAD 39/83 [ nSERVER:07c0: 2764] ### FP=0743f548,
	 PC=60197cf3, SP=0743ebd0, stksize=2424 Exception code: c0000005
	 (ACCESS_VIOLATION) ############################################################
	 @[ 1] 0x60197cf3 nnotes._Panic@4+483 (7430016,496dae76,0,496dace8) @[ 2]
	 0x600018a4 nnotes._OSBBlockAddr@8+148 (1153f38,2000000,743f608,1) @[ 3]
	 0x6000bd92 nnotes._CollectionNavigate@24+610 (0,743fc74,f,0) @[ 4] 0x600626cc
	 nnotes._ReadEntries@68+2860 (4c5440e8,4cfb8dba,800f,1) @[ 5] 0x600b9f6f
	 nnotes._NIFReadEntriesExt@72+351 (0,4cfb8dba,800f,1) @[ 6] 0x10032d40
	 nserverl._ServerReadEntries@8+1424 (0,8d0c0035,4b64b5bc,4ae46dd6) @[ 7]
	 0x100191fc nserverl._DbServer@8+2284 (41b0383,cb740064,0,23696f8) @[ 8]
	 0x1002b8c8 nserverl._WorkThreadTask@8+1576 (4711d68,0,3,563fb10) @[ 9]
	 0x100016cb nserverl._Scheduler@4+763 (0,563fb10,0,10ec334) @[10] 0x6011e5e4
	 nnotes._ThreadWrapper@4+212 (0,10ec334,563fb10,0) [11] 0x77e887dd
	 KERNEL32.GetModuleFileNameA+465
  -------------------------------------------

Когда процесс сбоя был определен, можно фокусироваться о том, как устранить неполадки того определенного процесса.

Работайте NSD вручную для "зависает" и проблемы производительности

Для доступа к справке NSD введите nsd - справка. Это - общее использование:

nsd -ini <notes_ini_file> -log <nsd_output_name> -dumpandkill

Удостоверьтесь, что NSD содержит стеки вызовов, данные памяти и notes.ini информацию перед передачей.

Диагностируйте проблемы с клиентом DUCS

Отслеживание может быть установлено на проигрывателе с настройкой реестра. Выполните следующие действия:

  1. Перейдите к HKEY_CURRENT_USER/Software/Lotus/DUCS ключу.

  2. Выберите Edit> New> DWORD Value.

  3. Назначьте название DebugFlags, тогда устанавливает значение в fff.

Выходной файл называют LotusUC.csv, и это найдено в каталоге данных Lotus.

Если проигрыватель завершается катастрофическим отказом, NSD должен работать. Если проигрыватель "зависает", NSD может все еще быть вызван вручную.

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


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


Document ID: 71316