ASR 9000 시리즈 제품에 설치된 IOS XR 이미지의 CPU/Memory 모니터링 방법은 기존 IOS 버전과 크게 다릅니다.
- IOS 에서는 하나의 프로세스로 CPU hook이 발생할 수 있으나 XR 이미지에서는 유사한 문제가 발생하지 않습니다.
- IOS 가 사용하던 것과 같은 CPU 총 사용률은 없습니다. 또한 모든 IOS XR 라우터에는 적어도 듀얼 코어 CPU가 있고 메모리 모니터링도 프로세스별로 수행됩니다.
- 사용 가능한 메모리가 거의 없다는 것 자체가 문제가 되지 않습니다.기본적으로 1M의 메모리를 할당 받은 단일 프로세스는 1M을 모두 사용하지 않을 수 있지만, 시간이 지남에 따라 100k, 200k, 300k이런식으로 계속 증가한다면 이는 메모리 누수의 신호일 수 있습니다.
- 여기서 좋은 점은 메모리 누수가 발생할 때도 해당 프로세스에만 영향을 미치고 다른 것에는 영향을 주지 않는다는 것입니다.
Process Monitoring - 프로세스 모니터링
- 대부분의 사용자는 CPU 사용률로 라우터 상태를 확인하는데 익숙합니다.
- IOS XR 라우터의 분산된 작동 특성을 고려할 때, Active RP의 높은 CPU 사용률이 반드시 문제를 나타내는 것은 아닙니다.
- XR 라우터는 장시간 동안 100% 사용률로 작동할 수 있으며 다양한 프로세스가 실행되는 환경에서 CPU 사용률의 Peak와 trough는 정상입니다. “Normal”한 CPU 사용율은 사용 중인 XR 버전, 하드웨어 구성,사용되는 기능 및 구성 방법에 따라 달라집니다.
- Active RP, Standby RP CPU와 라인 카드 CPU를 함께 모니터링하면 시스템 동작을 자세히 모니터링할 수 있습니다.
- CPU 사용율은 “show process cpu location <loc>” CLI 명령으로 확인할 수 있고 실시간 모니터링은 “monitor process / monitor threads” CLI 명령으로 확인할 수 있습니다. 이러한 명령어를 실행하면 그 자체로 CPU 사용률이 약간 증가합니다.
- 다른 노드에서 “top procs”는 “run top_procs –l node0_<slot|RP0|RP1>_CPU0” CLI 명령으로 확인할 수 있습니다.
- WDSysmon은 시스템에서 프로세스의 동작을 모니터링합니다. 프로세스가 CPU를 hogging하는 것으로 인지되면 WDsysmon이 프로세스를 리셋 하여 CPUHog를 종료하고 관련 데이터를 기록합니다.
- OS 내의 프로세스는 0에서 63 사이의 우선순위를 할당하며, 대부분의 프로세스는 레벨 10으로 동작합니다.
- 우선순위 값은 스케줄러에서 CPU 런타임을 가져올 프로세스를 결정하는 데 사용됩니다.
- WDsysmon은 63레벨에서 동작하며 낮은 우선순위의 프로세스를 종료할 수 있습니다. CPUHog가 감지되더라도 아래 리스트의 프로세스를 종료하면 시스템이 불안정해질 수 있으므로 WDsysmon에 의해 종료되지 않습니다.
- Wdsysmon은 특정 프로세스가 총CPU 런타임의 25%를 소비할 때 CPUHog를 선언합니다.
- Wdsysmon은 CPUHog가 감지되고 20초 후에 로그 메시지를 생성하며 30초 동안 지속될 경우 해당 프로세스를 종료하고 Active RP의 bootflash에 덤프를 기록합니다.
- 프로세스를 종료하고 RP를 리셋 하기 전에 덤프가 완료될 때까지150초를 더 기다리고 CPUHog가 감지되고 프로세스가 종료된 경우 다음과 같은 로그 메시지가 생성됩니다:
- 어떤 프로세스가 “hogging”으로 기록되었는지는 “show watchdog trace | inchog” CLI 명령으로 확인할 수 있습니다.
- 비정상적으로 종료된 프로세스에 대한 정보는 “show process abort” 또는 “show sysmgr trace verbose | iPROC_ABORT” 로 확인할 수 있고, “show context location all” 명령을 사용하여 프로세스 충돌이 발생한 정보를 확인할 수 있습니다.
Memory Monitoring - 메모리 모니터링
- Wdsysmon은 각 노드(RP 및 라인카드)의 메모리 상태를 정기적으로 확인하여 메모리 누수 감지를 수행합니다.
- Normal, Minor, Severe 및 Critical 네 가지 상태 임계값으로 구분하고 노드 상태 임계값의 정의는 물리적 메모리의 크기에 따라 달라집니다.
- 예를 들어 물리적 메모리가 4GB인 노드의 경우 기본적으로 사용 가능한 메모리가 80Mb보다 크면 메모리 상태가 Normal로 간주되고 메모리 상태는 “show watchdog memory-state <location>” CLI 명령으로 확인할 수 있습니다.
메모리 상태가 NORMAL에서 Minor로 변경되면 아래와 같은 syslog 메시지가 생성됩니다.
- Wdsysmon은 메모리 부족 상태에서 복구하는 절차가 있습니다.
- Wdsysmon은 노드의 상태가 Severe일때 과도한 메모리를 보유하고 있는 프로세스들을 식별하고 메모리를 확보하기 위해 프로세스를 리셋 하기 전에 프로세스 상태 정보를 가져옵니다. 이 상황에는 다음과 같은 syslog 메시지가 수반됩니다:
%HA-HA_WD-4-TOP_MEMORY_USER_WARNING [dec]: Process Name: [chars][[dec]], pid: [dec][chars], Kbytes used: [dec]
- 디폴트 메모리 임계값은 “show watchdog threshold memory defaults location <node>” CLI 명령으로 확인할 수 있습니다.
- “watchdog threshold memory location” 을 사용하여 디폴트 임계값을 변경할 수 있습니다. P 라우터의 메모리 임계값은 20% minor, 10% severe 및 5% critical을 권장합니다.
(config)#watchdog threshold memory location 0/RP0/CPU0 minor 20 severe 10 critical 5
- 설정한 메모리 임계값은 “show watchdog threshold memory configured location <node>” CLI 명령으로 확인할 수 있습니다.
Memory usage analyser 는 라우터의 모든 프로세스의 heap 메모리 사용량에 대한 세부 정보를 두 개의 서로 다른 스냅샷에 기록하고 결과를 비교하여 메모리 값이 증가되거나 감소된 프로세스를 알려주며 아래와 같이 사용할 수 있습니다.
1. “show mem compare start” CLI 명령으로 초기 스냅샷을 만듭니다
2. “show mem compare end” CLI 명령으로 다른 스냅샷을 만듭니다
3. “show mem compare report” CLI 명령으로 결과를 확인합니다
- 해당 결과에는 테스트 동안 각 프로세스의 heap 메모리의 사용량 변화에 대한 정보가 포함되며 증가폭이 큰 순서로 나열됩니다. 이는 메모리 누수를 감지하는 가장 효율적인 방법이며 각 프로세스에 대해 다음 정보를 확인할 수 있습니다.
JID Process Job ID
Name Process name
mem before Heap memory usage at start (in bytes)
mem after Heap memory usage at end (in bytes)
difference Difference in heap memory usage (in bytes)
mallocs Number of unfreed allocations made during test period
restarted Indicates if the process was restarted during test period
참고 문서: https://community.cisco.com/t5/service-providers-knowledge-base/asr9000-xr-monitoring-cpu-and-memory/ta-p/3145787