Este documento proporciona los pasos para ayudar en la supervisión y resolución de problemas relacionados con el uso elevado del procesador en Cisco Unified Communications Manager 6.0 con RTMT.
Cisco le recomienda que tenga conocimiento acerca de este tema:
Cisco Unified Communications Manager
La información que figura en el presente documento se basa en los siguientes temas del programa:
Hora del sistema, Hora del usuario, IOWait, IRQ de software e IRQ
Código amarillo, pero el uso total de la CPU es de solo el 25% - ¿Por qué?
La información de este documento se basa en Cisco Unified Communications Manager 6.0.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). If your network is live, make sure that you understand the potential impact of any command.
La utilización de RTMT para aislar posibles problemas con la CPU puede ser un paso muy útil para la resolución de problemas.
Estos términos representan el uso de los informes de la página Memoria y CPU de RTMT:
%Sistema: el porcentaje de utilización de la CPU que se produjo en la ejecución a nivel del sistema (kernel)
%Usuario: el porcentaje de utilización de la CPU que se ha producido en la ejecución a nivel de usuario (aplicación)
%IOWait: el porcentaje de tiempo que la CPU estuvo inactiva mientras esperaba una solicitud de E/S de disco pendiente
%SoftIRQ: el porcentaje de tiempo que el procesador ejecuta el procesamiento IRQ diferido (por ejemplo, el procesamiento de paquetes de red)
%IRQ el porcentaje de tiempo que el procesador ejecuta la solicitud de interrupción, que se asigna a los dispositivos para la interrupción, o envía una señal al equipo cuando finaliza el procesamiento
Las alertas CPUPegging/CallProcessNodeCPUPegging supervisan el uso de la CPU en función de los umbrales configurados:
Nota: %CPU se calcula como %system + %user + %nice + %iowait + %softirq + %irq
Los mensajes de alerta incluyen:
%system, %user, %nice, %iowait, %softirq y %irq
El proceso que utiliza la mayor cantidad de CPU
Los procesos que esperan en la suspensión de disco ininterrumpible
Las alertas de trazabilidad de CPU pueden aparecer en RTMT debido a un mayor uso de CPU que lo que se define como el nivel de marca de agua. Dado que CDR es una aplicación que hace un uso intensivo de la CPU cuando se carga, compruebe si recibe las alertas en el mismo período que cuando CDR está configurado para ejecutar informes. En este caso, puede ser necesario aumentar los valores de umbral en RTMT. Consulte Alertas para obtener más información sobre las alertas RTMT.
Si %system y/o %user es lo suficientemente alto como para generar una alerta de CpuPegging, verifique el mensaje de alerta para ver qué procesos utilizan más CPU.
Nota: Vaya a la página Proceso RTMT y ordene por %CPU para identificar los procesos de CPU con un uso elevado.
Nota: Para el análisis postmortem, el registro de rendimiento de Troubleshooting de RIS realiza un seguimiento del proceso %uso de CPU y lo hace a nivel del sistema.
Alta %IOWait indica alta actividad de E/S de disco. Tenga en cuenta lo siguiente:
IOWait se debe a un intercambio de memoria intenso.
Verifique el %CPU Time for Swap Partition para ver si hay un alto nivel de actividad de intercambio de memoria. Dado que Muster tiene al menos 2G RAM, el intercambio de memoria alta es probable debido a una fuga de memoria.
IOWait se debe a la actividad DB.
DB es principalmente el único que accede a Active Partition. Si el tiempo de la CPU %para la partición activa es alto, es probable que haya mucha actividad de la base de datos.
Partición común (o registro) es la ubicación en la que se almacenan los archivos de seguimiento y registro.
Nota: Marque estas opciones:
Central de seguimiento y registro: ¿existe alguna actividad de recopilación de seguimiento? Si el procesamiento de llamadas se ve afectado (es decir, CodeYellow), ajuste la programación de la recopilación de seguimiento. Además, si se utiliza la opción zip, desactívela.
Configuración de seguimiento: en el nivel Detallado, CallManager genera bastante seguimiento. Si el valor alto de %IOWait y/o CCM está en el estado CodeYellow y la configuración de seguimiento del servicio CallManager está en Detailed, intente cambiarlo a "Error".
No hay una forma directa de averiguar el uso de %IOWait por proceso. Actualmente, la mejor manera es comprobar los procesos que están esperando en el disco.
Si %IOWait es lo suficientemente alto como para causar una alerta de CpuPegging, verifique el mensaje de alerta para determinar los procesos que esperan la E/S del disco.
Vaya a la página Proceso RTMT y ordene por Estado. Compruebe si hay procesos en el estado de suspensión del disco ininterrumpible. El proceso SFTP utilizado por TLC para la recolección programada se encuentra en el estado de suspensión de disco ininterrumpible.
Nota: El archivo RIS Troubleshooting PerfMon Log se puede descargar para examinar el estado del proceso durante períodos de tiempo más largos.
En la Herramienta de monitoreo en tiempo real, vaya a System > Tools > Trace > Trace & Log Central.
Haga doble clic en Collect Files y elija Next.
Elija Cisco RIS Data Collector PerfMonLog y elija Next.
En el campo Tiempo de Recopilación, configure el tiempo necesario para ver los archivos de registro del período en cuestión. En el campo Download File Options, busque la ruta de descarga (una ubicación desde la que puede iniciar el Monitor de rendimiento de Windows para ver el archivo de registro), elija Zip Files y elija Finish.
Observe el progreso de Recopilar archivos y la ruta de descarga. No se debe informar de ningún error aquí.
Vea los archivos de registro de rendimiento con la herramienta Monitor de rendimiento de Microsoft. Elija Inicio > Configuración > Panel de control > Herramientas administrativas > Rendimiento.
En la ventana de la aplicación, haga clic con el botón derecho y elija Propiedades.
Elija la ficha Origen en el cuadro de diálogo Propiedades del Monitor de sistema. Elija Log files: como origen de datos y haga clic en el botón Agregar.
Busque el directorio donde descargó el archivo de registro de PerfMon y elija el archivo perfmon csv. El archivo de registro incluye esta convención de nomenclatura:
PerfMon_<node>_<month>_<day>_<year>_<hour>_<minute>.csv; por ejemplo, PerfMon_10.89.35.218_6_20_2005_11_27.csv.
Haga clic en Apply (Aplicar).
Haga clic en el botón Intervalo de tiempo. Para especificar el rango de tiempo en el archivo de registro de PerfMon que desea ver, arrastre la barra hasta las horas de inicio y finalización apropiadas.
Para abrir el cuadro de diálogo Agregar contadores, haga clic en la pestaña Datos y haga clic en Agregar. En el cuadro desplegable Performance Object (Objeto de rendimiento), agregue Process. Elija Estado del proceso y haga clic en Todas las instancias. Cuando termine de seleccionar los contadores, haga clic en Cerrar.
Sugerencias para ver el registro:
Establezca la escala vertical del gráfico en Máximo 6.
Céntrese en cada proceso y observe el valor máximo de 2 o superior.
Elimine los procesos que no estén en suspensión de disco ininterrumpible.
Utilice la opción de realzado.
Nota: Estado del proceso 2 = suspensión ininterrumpida del disco es sospechoso. Otras posibilidades de estado son 0-running, 1-sleep, 2-Uninterruptible disk sleep, 3-Zombie, 4-Tracing o detenido, 5-Paging, 6-Unknown
La alerta de código amarillo se genera cuando el servicio CallManager entra en el estado de código amarillo. Para obtener más información sobre el estado amarillo del código, consulte Regulación de llamadas y estado amarillo del código. La alerta CodeYellow se puede configurar para descargar archivos de seguimiento para solucionar problemas.
El contador AverageExpectedDelay representa el retraso esperado promedio actual para manejar cualquier mensaje entrante. Si el valor está por encima del valor especificado en el parámetro de servicio "Latencia de entrada de código amarillo", se genera la alarma CodeYellow. Este contador puede ser un indicador clave del rendimiento del procesamiento de llamadas.
Es posible que CallManager entre en el estado CodeYellow debido a una falta de recursos del procesador cuando el uso total de la CPU es solamente alrededor del 25-35 por ciento en un cuadro de 4 procesadores virtuales.
Nota: Con Hyper-Threading activado, un servidor con dos procesadores físicos tiene cuatro procesadores virtuales.
Nota: Del mismo modo, en un servidor de dos procesadores, CodeYellow es posible con aproximadamente un 50 por ciento de uso total de la CPU.
Si RTMT envía el mensaje, el estado del servicio es INACTIVO. Interfaz de mensajería de Cisco. , debe desactivar el servicio Cisco Messaging Interface si CUCM no está integrado con un sistema de mensajería de voz de terceros. Si desactiva el servicio de interfaz de mensajería de Cisco, detiene las alertas adicionales de RTMT.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
22-Jun-2007
|
Versión inicial |