RTMT(Real Time Monitoring Tool)를 사용한 Cisco Unified Communications Manager 6.0 High CPU 모니터링 및 문제 해결

다운로드 옵션

PDF (299.9 KB)
다양한 디바이스에서 Adobe Reader로 보기
ePub (91.4 KB)
iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
Mobi (Kindle) (82.6 KB)
Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기

업데이트:2009년 1월 30일

문서 ID:97086

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

이 문서에서는 RTMT를 사용하는 Cisco Unified Communications Manager 6.0의 높은 프로세서 사용률과 관련된 문제를 모니터링하고 해결하는 데 도움이 되는 단계를 제공합니다.

사전 요구 사항

요구 사항

Cisco에서는 다음 항목에 대해 알고 있는 것이 좋습니다.

Cisco Unified Communications Manager

사용되는 구성 요소

이 문서의 정보는 다음 의제를 기반으로 합니다.

시스템 시간, 사용자 시간, IOWait, Soft IRQ 및 IRQ
CPU 페깅 경고
CPU를 가장 많이 사용하는 프로세스 식별
높은 IOWait
일반 파티션으로 인한 HighIOWait
디스크 I/O를 담당하는 프로세스 식별
코드 노란색
코드 노란색이지만 총 CPU 사용량이 25%에 불과합니다. 그 이유는 무엇입니까?

이 문서의 정보는 Cisco Unified Communications Manager 6.0을 기반으로 합니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참고하십시오.

시스템 시간, 사용자 시간, IOWait, Soft IRQ 및 IRQ

RTMT를 활용하여 CPU의 잠재적 문제를 격리하면 매우 유용한 문제 해결 단계가 될 수 있습니다.

다음 용어는 RTMT CPU 및 메모리 페이지 보고서의 사용량을 나타냅니다.

%시스템: 시스템 레벨(커널)에서 실행되는 동안 발생한 CPU 사용률
%사용자: 사용자 레벨(애플리케이션)에서 실행되는 동안 발생한 CPU 사용률
%IOWait: 해결되지 않은 디스크 I/O 요청을 기다린 CPU가 유휴 상태인 시간의 백분율
%소프트 IRQ: 프로세서가 지연된 IRQ 처리(예: 네트워크 패킷 처리)를 실행하는 시간의 백분율
%IRQ 프로세서가 인터럽트 요청을 실행하는 시간의 백분율입니다. 인터럽트 요청은 인터럽트를 위해 장치에 할당되거나 처리가 완료되면 컴퓨터에 신호를 보냅니다

CPU 페깅 경고

CPUPegging/CallProcessNodeCPUPegging 알림은 구성된 임계값을 기반으로 CPU 사용량을 모니터링합니다.

참고: %CPU는 %system + %user + %nice + %iowait + %softirq + %irq로 계산됩니다.

알림 메시지는 다음과 같습니다.

%system, %user, %nice, %iowait, %softirq 및 %irq
CPU를 가장 많이 사용하는 프로세스
Uninterruptible 디스크 절전 모드에서 대기하는 프로세스

CPU 페깅 경고는 워터마크 수준으로 정의된 것보다 높은 CPU 사용량으로 인해 RTMT에 나타날 수 있습니다. CDR은 로드할 때 CPU를 많이 사용하는 애플리케이션이므로 CDR이 보고서를 실행하도록 구성된 기간과 동일한 기간에 알림을 수신하는지 확인합니다. 이 경우 RTMT의 임계값을 늘려야 합니다. RTMT 알림에 대한 자세한 내용은 알림을 참조하십시오.

CPU를 가장 많이 사용하는 프로세스 식별

%system 및/또는 %user가 CpuPegging 경고를 생성할 수 있을 만큼 높으면 경고 메시지를 확인하여 가장 많은 CPU를 사용하는 프로세스를 확인합니다.

참고: RTMT Process 페이지로 이동하여 %CPU별로 정렬하여 높은 CPU 프로세스를 확인하십시오.

참고: 사후 분석을 위해 RIS 트러블슈팅 PerfMon 로그는 프로세스 %CPU 사용량을 추적하며 시스템 레벨에서 추적합니다.

높은 IOWait

높음 %IOWait는 높은 디스크 I/O 작업을 나타냅니다. 다음 사항을 고려하십시오.

IOWait는 메모리 스와핑이 많기 때문입니다.

스왑 파티션에 대한 %CPU 시간을 확인하여 높은 수준의 메모리 스와핑 작업이 있는지 확인합니다. Muster는 최소 2G RAM을 가지고 있으므로 메모리 누수로 인해 메모리 스와핑이 발생할 가능성이 높습니다.
IOWait는 DB 활동 때문입니다.

DB는 주로 활성 파티션에 액세스하는 유일한 DB입니다. 활성 파티션의 %CPU 시간이 길면 DB 작업이 많을 수 있습니다.

일반 파티션으로 인한 높은 IOWait

Common(또는 Log) Partition은 추적 및 로그 파일이 저장되는 위치입니다.

참고: 다음 사항을 확인하십시오.

Trace & Log Central(추적 및 로그 센트럴) - 추적 수집 활동이 있습니까? 통화 처리가 영향을 받는 경우(즉, CodeYellow) 추적 수집 일정을 조정합니다. 또한 zip 옵션을 사용하는 경우 해당 기능을 끕니다.
추적 설정 - 세부 레벨에서 CallManager는 꽤 많은 추적을 생성합니다. 높음 %IOWait 및/또는 CCM이 CodeYellow 상태이고 CallManager 서비스 추적 설정이 Detailed인 경우 "Error"로 변경해 보십시오.

디스크 I/O를 담당하는 프로세스 식별

프로세스당 %IOWait 사용량을 확인할 수 있는 직접적인 방법은 없습니다. 현재 가장 좋은 방법은 디스크에서 대기 중인 프로세스를 확인하는 것입니다.

%IOWait가 CpuPegging 경고를 일으킬 수 있을 만큼 높으면 경고 메시지를 확인하여 디스크 I/O를 기다리는 프로세스를 확인합니다.

RTMT Process(RTMT 프로세스) 페이지로 이동하여 Status(상태)별로 정렬합니다. Uninterruptible disk sleep 상태의 프로세스를 확인합니다. TLC가 예약 수집에 사용하는 SFTP 프로세스는 Uninterruptible disk sleep 상태에 있습니다.

참고: RIS 트러블슈팅 PerfMon 로그 파일을 다운로드하여 더 긴 시간 동안 프로세스 상태를 검토할 수 있습니다.

Real Time Monitoring Tool에서 System > Tools > Trace > Trace & Log Central로 이동합니다.
Collect Files(파일 수집)를 두 번 클릭하고 Next(다음)를 선택합니다.
Cisco RIS Data Collector PerfMonLog를 선택하고 Next(다음)를 선택합니다.
Collection Time 필드에서 해당 기간의 로그 파일을 보는 데 필요한 시간을 구성합니다. 파일 다운로드 옵션 필드에서 다운로드 경로(Windows 성능 모니터를 실행하여 로그 파일을 볼 수 있는 위치)를 탐색하고 Zip 파일을 선택한 다음 마침을 선택합니다.
Collect Files(파일 수집) 진행 및 다운로드 경로를 확인합니다. 여기서는 오류를 보고하지 않습니다.
Microsoft 성능 모니터 도구를 사용하여 성능 로그 파일을 봅니다. 시작 > 설정 > 제어판 > 관리 도구 > 성능을 선택 합니다.
응용 프로그램 창에서 마우스 오른쪽 단추를 누르고 등록 정보를 선택합니다.
시스템 모니터 속성 대화 상자에서 소스 탭을 선택합니다. Log files(로그 파일)를 선택합니다. 를 데이터 소스로 설정하고 Add(추가) 버튼을 클릭합니다.
PerfMon Log 파일을 다운로드한 디렉토리로 이동하여 perfmon csv 파일을 선택합니다. 로그 파일에는 다음과 같은 명명 규칙이 포함됩니다.

PerfMon_<노드>_<월>_<일>_<년>_<시간>_<분>.csv; 예: PerfMon_10.89.35.218_6_20_2005_11_27.csv.
적용을 클릭합니다.
Time Range(시간 범위) 버튼을 클릭합니다. 보려는 PerfMon 로그 파일에서 시간 범위를 지정하려면 막대를 적절한 시작 및 종료 시간으로 드래그합니다.
카운터 추가 대화 상자를 열려면 데이터 탭을 클릭하고 추가를 클릭합니다. Performance Object(성능 개체) 드롭다운 상자에서 Process를 추가합니다. Process Status(프로세스 상태)를 선택하고 All instances(모든 인스턴스)를 클릭합니다. 카운터 선택을 완료하면 닫기를 클릭합니다.
로그를 볼 때의 팁:
- 그래프 수직 배율을 Maximum 6으로 설정합니다.
- 각 프로세스에 초점을 맞추고 최대 값 2를 확인합니다.
- Uninterruptible disk sleep에 있지 않은 프로세스를 삭제합니다.
- 강조 표시 옵션을 사용합니다.
참고: Process Status 2 = Uninterruptible disk sleep is suspect. 다른 상태 가능성은 0 실행, 1 절전, 2 무정전 디스크 절전, 3 좀비, 4 추적 또는 중지, 5 페이징, 6 알 수 없음

코드 노란색

CallManager 서비스가 코드 노란색 상태가 되면 코드 노란색 알림이 생성됩니다. 코드 노란색 상태에 대한 자세한 내용은 통화 제한 및 코드 노란색 상태를 참조하십시오. 문제 해결을 위해 추적 파일을 다운로드하도록 CodeYellow 알림을 구성할 수 있습니다.

AverageExpectedDelay 카운터는 인바운드 메시지를 처리할 현재 평균 예상 지연을 나타냅니다. 값이 "Code Yellow Entry Latency" 서비스 매개변수에 지정된 값보다 크면 CodeYellow 경보가 생성됩니다. 이 카운터는 통화 처리 성능을 나타내는 하나의 주요 지표일 수 있습니다.

CodeYellow이지만 총 CPU 사용량은 25%에 불과합니다. 그 이유는 무엇입니까?

4개의 가상 프로세서 박스에서 총 CPU 사용량이 25-35% 정도에 불과할 경우 프로세서 리소스가 부족하여 CallManager가 CodeYellow 상태로 전환될 수 있습니다.

참고: 하이퍼스레딩이 켜져 있는 상태에서 물리적 프로세서가 2개인 서버에는 4개의 가상 프로세서가 있습니다.

참고: 마찬가지로, 두 개의 프로세서 서버에서 CodeYellow는 총 CPU 사용량의 약 50%를 차지할 수 있습니다.

경고: "서비스 상태가 DOWN입니다. Cisco 메시징 인터페이스"

RTMT에서 서비스 상태를 전송하는 경우 DOWN입니다. Cisco 메시징 인터페이스. 경고: CUCM이 타사 음성 메시징 시스템과 통합되지 않은 경우 Cisco 메시징 인터페이스 서비스를 비활성화해야 합니다. Cisco Messaging Interface 서비스를 비활성화하면 RTMT에서 추가 알림이 중지됩니다.