# Troubleshooting high CPU and service crashes in Unified CM

Canonical: https://warmtransfer.net/knowledge/cucm-high-cpu-troubleshooting

Last verified: 2026-10-02

In Unified CM, the Cisco CallManager service can stop responding when it lacks resources such as CPU or memory, and conditions that cause excessive delay before dial tone put the system into Code Yellow, where new call attempts are throttled or denied[^4][^42]. Cisco documents RTMT alerts for call throttling, downed services and core dumps, and specifies the logs to collect for Cisco TAC[^10][^24][^20][^37].

## How call throttling and Code Yellow work

Unified CM call throttling automatically throttles or denies new call attempts when conditions would cause excessive delay between going off hook and receiving dial tone, and in that state the system is in Code Yellow[^42]. Cisco lists heavy call activity, low CPU availability, routing loops, disk I/O limitations and disk fragmentation as conditions that can delay dial tone and trigger call throttling[^41]. While throttling is active, a user attempting a new call receives a reorder tone and, depending on phone model, may also see a prompt on the phone display[^45].

The RTMT CodeYellow alert indicates that Unified CM initiated call throttling due to unacceptably high delay in handling calls[^10]. Cisco's high-CPU technote states that the CodeYellow alarm is raised when the AverageExpectedDelay counter, the current average expected delay to handle an inbound message, exceeds the Code Yellow Entry Latency service parameter[^11]. Unified CM stops throttling calls and exits Code Yellow on its own once delay to dial tone is back within the call throttling service parameter guidelines[^40].

The call throttling parameters, including Code Yellow Entry Latency and Code Yellow Duration, are under System > Service Parameters, Cisco CallManager service, Advanced, in the Call Throttling section[^44]. Cisco recommends not modifying these parameters unless customer support advises it[^43].

In CallManager 4.2 alarm documentation, CodeRedEntry means CallManager could not recover even after call throttling and the CallManager service is shut down[^9]. The recommended action in that 4.2 documentation is to find the cause of high CPU in the High and Normal priority queues[^9].

## RTMT alerts for CPU and crash conditions

In the RTMT 15 Alerts chapter, CpuPegging, CriticalServiceDown and CoreDumpFileFound are listed among the System Alerts[^34]. CallProcessingNodeCpuPegging and CodeYellow are listed among the Voice and Video Alerts, not the System Alerts[^35].

The CriticalServiceDown alert is generated when any service is down[^24]. The CoreDumpFileFound alert is generated when the Unified RTMT backend service detects a new core dump file[^20].

For certain preconfigured alerts, including CriticalServiceDown, CoreDumpFileFound and CodeYellow, traces can be captured automatically by checking Enable Trace Download in Set Alert/Properties[^1]. Cisco cautions that alert-triggered Trace Download may affect services on the node and that a high number of downloads adversely impacts service quality on the node[^48].

For LowAvailableVirtualMemory, Cisco's technote says Linux virtual memory usage can accumulate over time and recommends a server reboot[^27]. When the log partition reaches the LogPartitionHighWaterMarkExceeded threshold, the server starts auto-purging the oldest logs, so Cisco advises purging manually once the low water mark alert fires[^26].

## When the CallManager service stops or crashes

Cisco's troubleshooting guide says the Cisco CallManager service can stop responding when it lacks resources such as CPU or memory, and that CPU utilisation is generally 100 percent at that time[^4]. A message may then appear stating that the service terminated unexpectedly, with a count of how many times this has happened[^6].

In Cisco's 8.5(1) alarm documentation, the CallManagerFailure alarm reports an internal failure in the Cisco CallManager service with these reason codes: 1 Unknown, 2 HeartBeatStopped, 3 RouterThreadDied, 4 TimerThreadDied and 5 CriticalThreadDied[^7]. The service should restart to clear the failure[^7].

In the I/O-wait scenario of Cisco's UCS common-problems technote, the CCM core backtrace showed CallManager unable to process signals, which Cisco describes as possibly due to CPU or a blocked function[^2].

## Diagnosing high CPU in real time

If high CPU or memory use is happening in real time, Cisco TAC asks for output of `show process using-most cpu` (or `memory`), `show process load`, `utils diagnose test` and `show status`[^39]. `utils diagnose test` runs all diagnostic commands but does not attempt to fix problems[^57].

In RTMT, %IOWait is the percentage of time the CPU was idle while waiting for an outstanding disk I/O request[^33]. This is distinct from %User, which measures application-level utilisation, and %System, which measures kernel-level utilisation[^33].

For I/O-wait investigations, Cisco's UCS technote enables File I/O Reporting with `utils fior start` and `utils fior enable`, and collects the results with `file get activelog platform/io-stats`[^25]. In that technote, high CPU from I/O wait that restarted the CCM and CTI services was attributed to the UCS platform and its storage, and isolating the cause required UCS logs[^53].

Cisco notes that RAID controller background operations, namely Consistency Check, Background Initialization, Rebuild and Patrol Read, can significantly affect I/O performance[^32]. Cisco recommends scheduling Consistency Check and Patrol Read at times of low load[^32].

## Collecting evidence after a core dump

Cisco states that core dumps can be difficult to reproduce, so the associated log files should be collected when a core dump occurs and before the logs are overwritten[^18].

- To receive email on core dumps, select System > Tools > Alert > Alert Central in RTMT, right-click CoreDumpFileFound, choose Set Alert Properties, ensure Enable Email is checked, and add a recipient; the email server is set under System > Tools > Alert > Config Email Server.[^12]
- Note which services initiated the alert, which the alert email marks with the word Core.[^17]
- Use RTMT Tools > Trace & Log Central > Collect Files to collect logs for all impacted services, including services that interact with the one that cored.[^15]
- From the platform CLI, generate a stack trace by running `utils core active list` and then `utils core active analyze` with the core filename.[^19]
- Collect the RIS Data Collector PerfMon Log through Trace & Log Central > Collect Files.[^14]
- Collect system logs for the affected node through RTMT Tools > SysLog Viewer: System Logs > messages, and Application Logs > CiscoSyslog.[^16]
- Attach the collected service logs, stack trace, PerfMon log and syslogs to the Cisco technical support case.[^13]

`utils core {active | inactive} list` displays all core files for the active or the inactive software version[^56]. `utils core {active | inactive} analyze` generates a backtrace for a core file, a thread list, and the current values of all CPU registers[^54]. The analyze output is written to a file in the same directory as the core file, with the core file's name plus a.txt extension[^55].

## Collecting evidence for root cause

For root cause on a high CPU event that has already happened, TAC asks for traces that cover the period from before the problem began until after it went away[^38]. The TAC high-CPU RCA log set is detailed Cisco CallManager traces, Event Viewer Application and System logs, Cisco RISDC and Perfmon logs, Cisco AMC service logs, Cisco Tomcat and Tomcat Security logs, plus output of `show status`, `show process using-most cpu/memory`, `show process load` and `utils diagnose test`.[^37]

For a CallManager resource interruption, Cisco recommends collecting Cisco CallManager and SDL traces from 15 minutes before to 15 minutes after the interruption, plus perfmon traces[^3]. If no perfmon traces exist, Cisco recommends starting perfmon tracking of per-process CPU and memory[^3].

For CallManagerFailure, Cisco's recommended action in the 8.5(1) alarm documentation is to collect the core file if one is available, plus SDL and CCM/SDI traces from Trace and Log Central, and then contact Cisco TAC[^8].

Troubleshooting perfmon data logging writes monitored performance data in CSV format to the active log partition under var/log/active/cm/log/ris/csv[^30]. Cisco intends this data to help Cisco TAC identify system problems[^30].

## Trace levels and CPU load

Cisco states that enabling trace decreases system performance and that trace should be enabled only for troubleshooting[^46]. Detailed is the most verbose debug trace level: it traces all Arbitrary-level conditions plus detailed debugging information, and each level above Error is cumulative[^47]. The Error level traces alarm conditions and abnormal-path events and uses the minimum number of CPU cycles[^49].

Cisco's 6.0 high-CPU technote advises that when IOWait is high and the CallManager service trace is set to Detailed, the trace level be changed to Error[^58]. The same technote advises checking scheduled trace collection in Trace & Log Central during high IOWait and turning off the zip option if it is in use[^59].

Leaving troubleshooting trace enabled for a long time increases trace file size and may affect the performance of services[^51]. Before troubleshooting trace settings are applied, the system backs up the original trace settings, and resetting the troubleshooting traces restores those originals[^52]. Changing Maximum No. of Files or Maximum File Size in the Trace Configuration window deletes all of that service's log files except the current file[^50].

We infer that when high CPU coincides with CallManager tracing at Detailed or a long-running troubleshooting trace, lowering the trace level or resetting troubleshooting traces is a reasonable load-reduction step, but only after the traces needed for root cause have been collected[^28].

## See also

- [Unified CM RTMT alerts and monitoring](https://warmtransfer.net/knowledge/cucm-rtmt-alerts)
- [CUCM CallManager SDL trace files](https://warmtransfer.net/knowledge/cucm-sdl-trace-files)
- [Cisco unified cm](https://warmtransfer.net/knowledge/cisco-unified-cm)
- [Unified CM release trains and lifecycle dates](https://warmtransfer.net/knowledge/cucm-versions-lifecycle)

## Applicability

Applies to: Cisco Unified Communications Manager. Deployments: on-premises. Sources checked 2026-10-02. The RTMT alert, call throttling, trace and CLI claims come from Cisco documentation for Release 15 and SUs[^34][^42][^49][^54]. The AverageExpectedDelay description, the %IOWait definition and the IOWait trace recommendations come from a 6.0 technote[^11][^33][^58]. The CodeRedEntry definition comes from CallManager 4.2 alarm documentation[^9]. The I/O-wait storage scenario applies to UCS deployments[^53].

## What remains uncertain

Whether current releases such as Release 15 automatically restart CallManager after Code Yellow Duration elapses is not covered by the sources below. The only Code Red description here comes from CallManager 4.2 alarm documentation, and current-release Code Red behaviour has not been verified[^9]. The default thresholds for CallProcessingNodeCpuPegging, CpuPegging, CodeYellow and CoreDumpFileFound in RTMT 15 are not covered by the sources below. How to match CallManager core backtraces to known defects in Cisco Bug Search is not covered by the sources below. The default values of Code Yellow Entry Latency, Code Yellow Duration and Max Events Allowed are not covered by the sources below. The current Release 15 alarm message definitions for CallManagerFailure, CodeYellowEntry and CodeRedEntry are not covered by the sources below. VM sizing and CPU reservation or oversubscription as a cause of CUCM high CPU are not covered by the sources below. The `file get activelog` path syntax for downloading core files in the 15 CLI reference is not covered by the sources below. The database process cmoninit (Informix) as a driver of high CPU on a publisher or subscriber is not covered by the sources below.

## Sources

[^1]: For certain preconfigured RTMT alerts, including CriticalServiceDown, CoreDumpFileFound and CodeYellow, traces can be captured automatically by checking Enable Trace Download in Set Alert/Properties. Source: [Cisco Unified Real-Time Monitoring Tool Administration Guide, Release 15 and SUs - Alerts](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/15/rtmt/cucm_b_cisco-unified-rtmt-administration-15/cucm_b_cisco-unified-rtmt-administration-1251su2_chapter_0111.html), Alerts chapter > Automatic Trace Download Activation. Checked 2026-10-02.
[^2]: In the technote's I/O-wait scenario, the CCM core backtrace showed CallManager unable to process signals, which Cisco describes as possibly due to CPU or a blocked function. Source: [CUCM Common Problems on UCS Platform: Core, High CPU - I/O, Hung State](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/118702-technote-cucm-00.html), Scenario 1: High CPU Utilization Due to I/O Wait Issue > Verification (backtrace). Checked 2026-10-02.
[^3]: For a CallManager resource interruption, Cisco recommends collecting Cisco CallManager and SDL traces from 15 minutes before to 15 minutes after the interruption, plus perfmon traces; if none exist, start perfmon tracking of per-process CPU and memory. Source: [Troubleshooting Guide for Cisco Unified Communications Manager, Release 12.5(1) - Cisco Unified Communications Manager System Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_011.html), Cisco Unified Communications Manager System Stops Responding > recommended actions. Checked 2026-10-02.
[^4]: Cisco's troubleshooting guide says the Cisco CallManager service can stop responding when it lacks resources such as CPU or memory, and that CPU utilisation is generally 100 percent at that time. Source: [Troubleshooting Guide for Cisco Unified Communications Manager, Release 12.5(1) - Cisco Unified Communications Manager System Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_011.html), Cisco Unified Communications Manager System Stops Responding. Checked 2026-10-02.
[^5]: The Cisco CallManager System Performance perfmon object in Release 15 includes the counters AverageExpectedDelay, CodeYellowEntryExit, CodeRedEntryExit and CallsRejectedDueToThrottling. Source: [Cisco Unified Real-Time Monitoring Tool Administration Guide, Release 15 and SUs - Performance Counters](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/15/rtmt/cucm_b_cisco-unified-rtmt-administration-15/cucm_b_cisco-unified-rtmt-administration-1251su2_chapter_0110.html), Performance Counters > Cisco CallManager System Performance Object. Checked 2026-10-02.
[^6]: When the Cisco CallManager service stops responding, a message stating that the service terminated unexpectedly, with a count of how many times, may appear. Source: [Troubleshooting Guide for Cisco Unified Communications Manager, Release 12.5(1) - Cisco Unified Communications Manager System Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_011.html), Cisco Unified Communications Manager System Stops Responding. Checked 2026-10-02.
[^7]: The CallManagerFailure alarm reports an internal failure in the Cisco CallManager service with reason codes 1 Unknown, 2 HeartBeatStopped, 3 RouterThreadDied, 4 TimerThreadDied and 5 CriticalThreadDied; the service should restart to clear the failure. Source: [System Error Messages for Cisco Unified Communications Manager 8.5(1)](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/err_msgs/8_x/ccmalarms851.html), CallManagerFailure alarm entry. Checked 2026-10-02.
[^8]: For CallManagerFailure, Cisco's recommended action is to collect the core file if available plus SDL and CCM/SDI traces from Trace and Log Central and contact Cisco TAC. Source: [System Error Messages for Cisco Unified Communications Manager 8.5(1)](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/err_msgs/8_x/ccmalarms851.html), CallManagerFailure alarm entry > Recommended Action. Checked 2026-10-02.
[^9]: In CallManager 4.2 alarm documentation, CodeRedEntry means CallManager could not recover even after call throttling and the CallManager service is shut down; the recommended action is to find the cause of high CPU in the High and Normal priority queues. Source: [System Error Messages for Cisco Unified CallManager 4.2](https://www.cisco.com/en/US/docs/voice_ip_comm/cucm/err_msgs/4_x/alarms42.htm), CodeRedEntry alarm entry. Checked 2026-10-02.
[^10]: The RTMT CodeYellow alert indicates that Unified CM initiated call throttling due to unacceptably high delay in handling calls. Source: [Cisco Unified Real-Time Monitoring Tool Administration Guide, Release 15 and SUs - Alerts](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/15/rtmt/cucm_b_cisco-unified-rtmt-administration-15/cucm_b_cisco-unified-rtmt-administration-1251su2_chapter_0111.html), Alerts chapter > Automatic Trace Download Activation (alert list entry CodeYellow). Checked 2026-10-02.
[^11]: The CodeYellow alarm is raised when the AverageExpectedDelay counter (current average expected delay to handle an inbound message) exceeds the Code Yellow Entry Latency service parameter. Source: [Monitoring and Troubleshooting Cisco Unified Communications Manager 6.0 High CPU, using Real Time Monitoring Tool (RTMT)](https://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-callmanager/97086-ccm6-cpu.html), CodeYellow alert description section. Checked 2026-10-02.
[^12]: To be emailed on core dumps, select System > Tools > Alert > Alert Central in RTMT, right-click CoreDumpFileFound, choose Set Alert Properties, ensure Enable Email is checked and add a recipient; the email server is set under System > Tools > Alert > Config Email Server. Source: [Cisco Unified Real-Time Monitoring Tool Administration Guide, Release 15 and SUs - Alerts](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/15/rtmt/cucm_b_cisco-unified-rtmt-administration-15/cucm_b_cisco-unified-rtmt-administration-1251su2_chapter_0111.html), Alerts chapter > Set up alerts for core dump and collect relevant logs > Enable Email Alert, Steps 1-4. Checked 2026-10-02.
[^13]: The final step of Cisco's core dump procedure is to attach the collected files (service logs, stack trace, PerfMon log, syslogs) to the Cisco technical support case. Source: [Cisco Unified Real-Time Monitoring Tool Administration Guide, Release 15 and SUs - Alerts](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/15/rtmt/cucm_b_cisco-unified-rtmt-administration-15/cucm_b_cisco-unified-rtmt-administration-1251su2_chapter_0111.html), Alerts chapter > Set up alerts for core dump and collect relevant logs > Collect logs, Step 6. Checked 2026-10-02.
[^14]: The core dump log collection procedure includes collecting the RIS Data Collector PerfMon Log through Trace & Log Central > Collect Files. Source: [Cisco Unified Real-Time Monitoring Tool Administration Guide, Release 15 and SUs - Alerts](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/15/rtmt/cucm_b_cisco-unified-rtmt-administration-15/cucm_b_cisco-unified-rtmt-administration-1251su2_chapter_0111.html), Alerts chapter > Set up alerts for core dump and collect relevant logs > Collect logs, Step 4. Checked 2026-10-02.
[^15]: After a core dump, use RTMT Tools > Trace & Log Central > Collect Files to collect the logs for all impacted services, including services that interact with the one that cored. Source: [Cisco Unified Real-Time Monitoring Tool Administration Guide, Release 15 and SUs - Alerts](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/15/rtmt/cucm_b_cisco-unified-rtmt-administration-15/cucm_b_cisco-unified-rtmt-administration-1251su2_chapter_0111.html), Alerts chapter > Set up alerts for core dump and collect relevant logs > Collect logs, Step 2. Checked 2026-10-02.
[^16]: The core dump procedure also collects system logs through RTMT Tools > SysLog Viewer: System Logs > messages and Application Logs > CiscoSyslog for the affected node. Source: [Cisco Unified Real-Time Monitoring Tool Administration Guide, Release 15 and SUs - Alerts](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/15/rtmt/cucm_b_cisco-unified-rtmt-administration-15/cucm_b_cisco-unified-rtmt-administration-1251su2_chapter_0111.html), Alerts chapter > Set up alerts for core dump and collect relevant logs > Collect logs, Step 5. Checked 2026-10-02.
[^17]: The CoreDumpFileFound alert email indicates which services initiated the alert, marked by the word Core in the message, and that is the first thing to note when collecting logs. Source: [Cisco Unified Real-Time Monitoring Tool Administration Guide, Release 15 and SUs - Alerts](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/15/rtmt/cucm_b_cisco-unified-rtmt-administration-15/cucm_b_cisco-unified-rtmt-administration-1251su2_chapter_0111.html), Alerts chapter > Set up alerts for core dump and collect relevant logs > Collect logs, Step 1. Checked 2026-10-02.
[^18]: Cisco states that core dumps can be difficult to reproduce, so the associated log files should be collected when they occur and before they are overwritten. Source: [Cisco Unified Real-Time Monitoring Tool Administration Guide, Release 15 and SUs - Alerts](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/15/rtmt/cucm_b_cisco-unified-rtmt-administration-15/cucm_b_cisco-unified-rtmt-administration-1251su2_chapter_0111.html), Alerts chapter > Set up alerts for core dump and collect relevant logs (introduction). Checked 2026-10-02.
[^19]: To generate a stack trace for a core dump, run utils core active list and then utils core active analyze with the core filename from the platform CLI. Source: [Cisco Unified Real-Time Monitoring Tool Administration Guide, Release 15 and SUs - Alerts](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/15/rtmt/cucm_b_cisco-unified-rtmt-administration-15/cucm_b_cisco-unified-rtmt-administration-1251su2_chapter_0111.html), Alerts chapter > Set up alerts for core dump and collect relevant logs > Collect logs, Step 3. Checked 2026-10-02.
[^20]: The CoreDumpFileFound alert is generated when the Unified RTMT backend service detects a new core dump file. Source: [Cisco Unified Real-Time Monitoring Tool Administration Guide, Release 15 and SUs - Alerts](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/15/rtmt/cucm_b_cisco-unified-rtmt-administration-15/cucm_b_cisco-unified-rtmt-administration-1251su2_chapter_0111.html), Alerts chapter > Automatic Trace Download Activation (CoreDumpFileFound entry). Checked 2026-10-02.
[^21]: On a CpuPegging alert, Cisco suggests identifying the top process in RTMT (System > Process) and running utils diagnose test, show process load cpu sorted, show status and utils core active list. Source: [Real-Time Monitoring Tool Alerts](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/213291-real-time-monitoring-tool-alerts.html), CpuPegging section. Checked 2026-10-02.
[^22]: If CPU spikes happen at random times, Cisco advises gathering detailed CUCM traces and RisDC perfmon logs, plus logs for whichever process is using the most CPU. Source: [Real-Time Monitoring Tool Alerts](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/213291-real-time-monitoring-tool-alerts.html), CpuPegging section. Checked 2026-10-02.
[^23]: Cisco advises checking whether CPU spikes recur at a specific time, which would point to scheduled activity such as a Disaster Recovery System backup or CDR load. Source: [Real-Time Monitoring Tool Alerts](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/213291-real-time-monitoring-tool-alerts.html), CpuPegging section. Checked 2026-10-02.
[^24]: The CriticalServiceDown alert is generated when any service is down. Source: [Cisco Unified Real-Time Monitoring Tool Administration Guide, Release 15 and SUs - Alerts](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/15/rtmt/cucm_b_cisco-unified-rtmt-administration-15/cucm_b_cisco-unified-rtmt-administration-1251su2_chapter_0111.html), Alerts chapter > Automatic Trace Download Activation (CriticalServiceDown entry). Checked 2026-10-02.
[^25]: For I/O-wait investigations the technote enables File I/O Reporting with utils fior start and utils fior enable and collects results with file get activelog platform/io-stats. Source: [CUCM Common Problems on UCS Platform: Core, High CPU - I/O, Hung State](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/118702-technote-cucm-00.html), Scenario 1: High CPU Utilization Due to I/O Wait Issue > Verification. Checked 2026-10-02.
[^26]: When the log partition reaches the LogPartitionHighWaterMarkExceeded threshold the server starts auto-purging the oldest logs, so Cisco advises purging manually once the low water mark alert fires. Source: [Real-Time Monitoring Tool Alerts](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/213291-real-time-monitoring-tool-alerts.html), LogPartitionHighWaterMarkExceeded and LogPartitionLowWaterMarkExceeded section. Checked 2026-10-02.
[^27]: For the LowAvailableVirtualMemory alert, Cisco's technote says Linux virtual memory usage can accumulate over time and recommends a server reboot. Source: [Real-Time Monitoring Tool Alerts](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/213291-real-time-monitoring-tool-alerts.html), LowAvailableVirtualMemory section. Checked 2026-10-02.
[^28]: When high CPU coincides with CallManager tracing at Detailed or a long-running troubleshooting trace, lowering the trace level or resetting troubleshooting traces is a reasonable load-reduction step, but only after the traces needed for root cause are collected (inferred). Source: [Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Trace](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/15/adminGd/cucm_b_administration-guide-15/cucm_b_test-adminguide_chapter_011000.html), Trace > Debug Trace Level Settings; Troubleshooting Trace Settings. Checked 2026-10-02.
[^29]: Unified CM also supports memory-based throttling, turned on by setting the Enable Memory Throttling service parameter to True. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Configure Call Throttling](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_m_configure-call-throttling.html), Configure Call Throttling > Call Throttling Configuration Task Flow (memory throttling task). Checked 2026-10-02.
[^30]: Troubleshooting perfmon data logging writes monitored performance data in CSV format to the active log partition under var/log/active/cm/log/ris/csv, and is intended to help Cisco TAC identify system problems. Source: [Cisco Unified Real-Time Monitoring Tool Administration Guide, Release 15 and SUs - Performance Counters](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/15/rtmt/cucm_b_cisco-unified-rtmt-administration-15/cucm_b_cisco-unified-rtmt-administration-1251su2_chapter_0110.html), Performance Counters > Troubleshooting Perfmon Data Logging. Checked 2026-10-02.
[^31]: The perfmon logging polling rate defaults to 15 seconds and can be set as low as 5 seconds. Source: [Cisco Unified Real-Time Monitoring Tool Administration Guide, Release 15 and SUs - Performance Counters](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/15/rtmt/cucm_b_cisco-unified-rtmt-administration-15/cucm_b_cisco-unified-rtmt-administration-1251su2_chapter_0110.html), Performance Counters > Troubleshooting Perfmon Data Logging (polling rate parameter). Checked 2026-10-02.
[^32]: Cisco notes that RAID controller background operations (Consistency Check, Background Initialization, Rebuild, Patrol Read) can significantly affect I/O performance and recommends scheduling Consistency Check and Patrol Read at low load. Source: [Troubleshooting Guide for Cisco Unified Communications Manager, Release 12.5(1) - Cisco Unified Communications Manager System Issues](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/cucm_b_troubleshooting-guide-1251/cucm_b_troubleshooting-guide-1251_chapter_011.html), System issues chapter > RAID controller background operations. Checked 2026-10-02.
[^33]: In RTMT, %IOWait is the percentage of time the CPU was idle while waiting for an outstanding disk I/O request, distinct from %User (application level) and %System (kernel level) utilisation. Source: [Monitoring and Troubleshooting Cisco Unified Communications Manager 6.0 High CPU, using Real Time Monitoring Tool (RTMT)](https://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-callmanager/97086-ccm6-cpu.html), RTMT CPU and Memory page counter definitions. Checked 2026-10-02.
[^34]: In the RTMT 15 Alerts chapter, CpuPegging, CriticalServiceDown and CoreDumpFileFound are listed among the System Alerts. Source: [Cisco Unified Real-Time Monitoring Tool Administration Guide, Release 15 and SUs - Alerts](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/15/rtmt/cucm_b_cisco-unified-rtmt-administration-15/cucm_b_cisco-unified-rtmt-administration-1251su2_chapter_0111.html), Alerts chapter > Preconfigured alerts > System Alerts list. Checked 2026-10-02.
[^35]: In the RTMT 15 Alerts chapter, CallProcessingNodeCpuPegging and CodeYellow are listed among the Voice and Video Alerts rather than the System Alerts. Source: [Cisco Unified Real-Time Monitoring Tool Administration Guide, Release 15 and SUs - Alerts](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/15/rtmt/cucm_b_cisco-unified-rtmt-administration-15/cucm_b_cisco-unified-rtmt-administration-1251su2_chapter_0111.html), Alerts chapter > Preconfigured alerts > Voice and Video Alerts list. Checked 2026-10-02.
[^36]: The Release 15 CLI reference documents show process using-most cpu and show process load as privilege-level-0 admin commands that are allowed during upgrade. Source: [Command Line Interface Reference Guide for Cisco Unified Communications Solutions, Release 15 and SUs - Show Commands](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/cli_ref/15/cucm_b_cli_reference_guide_release_15/cucm_m_show-commands.html), Show Commands > show process using-most cpu; show process load. Checked 2026-10-02.
[^37]: The TAC high-CPU RCA log set is detailed Cisco CallManager traces, Event Viewer Application and System logs, Cisco RISDC and Perfmon logs, Cisco AMC service logs, Cisco Tomcat and Tomcat Security logs, plus show status, show process using-most cpu/memory, show process load and utils diagnose test output. Source: [Logs to be Collected for TAC when High CPU or Memory Issue is Noticed on CUCM](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/213679-logs-to-be-collected-for-tac-when-high-c.html), For RCA of an Event That Has Already Occurred (list). Checked 2026-10-02.
[^38]: For root cause on a high CPU event that already happened, TAC asks for traces covering the period from before the problem began until after it went away. Source: [Logs to be Collected for TAC when High CPU or Memory Issue is Noticed on CUCM](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/213679-logs-to-be-collected-for-tac-when-high-c.html), For RCA of an Event That Has Already Occurred. Checked 2026-10-02.
[^39]: If high CPU or memory is happening in real time, Cisco TAC asks for output of show process using-most cpu (or memory), show process load, utils diagnose test and show status. Source: [Logs to be Collected for TAC when High CPU or Memory Issue is Noticed on CUCM](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/213679-logs-to-be-collected-for-tac-when-high-c.html), CLI Output to be Collected If the Issue Occurs in Real Time. Checked 2026-10-02.
[^40]: Unified CM stops throttling calls and exits the Code Yellow state on its own once delay to dial tone is back within the call throttling service parameter guidelines. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Configure Call Throttling](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_m_configure-call-throttling.html), Configure Call Throttling > Call Throttling Overview. Checked 2026-10-02.
[^41]: Cisco lists heavy call activity, low CPU availability, routing loops, disk I/O limitations and disk fragmentation as conditions that can delay dial tone and trigger call throttling. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Configure Call Throttling](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_m_configure-call-throttling.html), Configure Call Throttling > Call Throttling Overview. Checked 2026-10-02.
[^42]: Unified CM call throttling automatically throttles or denies new call attempts when conditions would cause excessive delay between going off hook and receiving dial tone; in that state the system is in Code Yellow. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Configure Call Throttling](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_m_configure-call-throttling.html), Configure Call Throttling > Call Throttling Overview. Checked 2026-10-02.
[^43]: Cisco recommends not modifying the call throttling service parameters unless advised to do so by customer support. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Configure Call Throttling](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_m_configure-call-throttling.html), Configure Call Throttling > Configure Call Throttling (caution). Checked 2026-10-02.
[^44]: Call throttling parameters, including Code Yellow Entry Latency and Code Yellow Duration, are under System > Service Parameters, Cisco CallManager service, Advanced, in the Call Throttling section. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Configure Call Throttling](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_m_configure-call-throttling.html), Configure Call Throttling > Configure Call Throttling procedure. Checked 2026-10-02.
[^45]: When call throttling is active, a user attempting a new call receives a reorder tone and, depending on phone model, may also see a prompt on the phone display. Source: [Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Configure Call Throttling](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/cucm_b_feature-configuration-guide-for-15/cucm_m_configure-call-throttling.html), Configure Call Throttling > Call Throttling Overview. Checked 2026-10-02.
[^46]: Cisco states that enabling trace decreases system performance and that trace should be enabled only for troubleshooting. Source: [Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Trace](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/15/adminGd/cucm_b_administration-guide-15/cucm_b_test-adminguide_chapter_011000.html), Trace > Trace overview note and Configure Trace note. Checked 2026-10-02.
[^47]: Detailed is the most verbose debug trace level: it traces all Arbitrary-level conditions plus detailed debugging information, and each level above Error is cumulative. Source: [Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Trace](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/15/adminGd/cucm_b_administration-guide-15/cucm_b_test-adminguide_chapter_011000.html), Trace > Debug Trace Level Settings table. Checked 2026-10-02.
[^48]: Cisco cautions that RTMT alert-triggered Trace Download may affect services on the node and that a high number of downloads adversely impacts service quality on the node. Source: [Cisco Unified Real-Time Monitoring Tool Administration Guide, Release 15 and SUs - Alerts](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/15/rtmt/cucm_b_cisco-unified-rtmt-administration-15/cucm_b_cisco-unified-rtmt-administration-1251su2_chapter_0111.html), Alerts chapter > Automatic Trace Download Activation (caution). Checked 2026-10-02.
[^49]: The Error debug trace level traces alarm conditions and abnormal-path events and uses the minimum number of CPU cycles. Source: [Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Trace](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/15/adminGd/cucm_b_administration-guide-15/cucm_b_test-adminguide_chapter_011000.html), Trace > Debug Trace Level Settings table (Error). Checked 2026-10-02.
[^50]: Changing Maximum No. of Files or Maximum File Size in the Trace Configuration window deletes all of that service's log files except the current file. Source: [Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Trace](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/15/adminGd/cucm_b_administration-guide-15/cucm_b_test-adminguide_chapter_011000.html), Trace > Configure Trace (caution). Checked 2026-10-02.
[^51]: Leaving troubleshooting trace enabled for a long time increases trace file size and may affect the performance of services. Source: [Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Trace](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/15/adminGd/cucm_b_administration-guide-15/cucm_b_test-adminguide_chapter_011000.html), Trace > Troubleshooting Trace Settings. Checked 2026-10-02.
[^52]: Before troubleshooting trace settings are applied the system backs up the original trace settings, and resetting the troubleshooting traces restores those originals. Source: [Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Trace](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/15/adminGd/cucm_b_administration-guide-15/cucm_b_test-adminguide_chapter_011000.html), Trace > Troubleshooting Trace Settings. Checked 2026-10-02.
[^53]: In Cisco's UCS common-problems technote, high CPU from I/O wait that restarted the CCM and CTI services was attributed to the UCS platform and its storage, and isolating it needed UCS logs. Source: [CUCM Common Problems on UCS Platform: Core, High CPU - I/O, Hung State](https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/118702-technote-cucm-00.html), Scenario 1: High CPU Utilization Due to I/O Wait Issue > Resolution. Checked 2026-10-02.
[^54]: utils core {active | inactive} analyze generates a backtrace for a core file, a thread list and the current values of all CPU registers. Source: [Command Line Interface Reference Guide for Cisco Unified Communications Solutions, Release 15 and SUs - Utils Commands](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/cli_ref/15/cucm_b_cli_reference_guide_release_15/cucm_b_cli_reference_guide_release_1401_chapter_01001.html), Utils Commands > utils core analyze. Checked 2026-10-02.
[^55]: utils core analyze writes its output to a file with the same name as the core file plus a .txt extension, in the same directory as the core file. Source: [Command Line Interface Reference Guide for Cisco Unified Communications Solutions, Release 15 and SUs - Utils Commands](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/cli_ref/15/cucm_b_cli_reference_guide_release_15/cucm_b_cli_reference_guide_release_1401_chapter_01001.html), Utils Commands > utils core analyze > Usage Guidelines. Checked 2026-10-02.
[^56]: utils core {active | inactive} list displays all core files for the active or the inactive software version. Source: [Command Line Interface Reference Guide for Cisco Unified Communications Solutions, Release 15 and SUs - Utils Commands](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/cli_ref/15/cucm_b_cli_reference_guide_release_15/cucm_b_cli_reference_guide_release_1401_chapter_01001.html), Utils Commands > utils core list. Checked 2026-10-02.
[^57]: utils diagnose test runs all diagnostic commands but does not attempt to fix problems. Source: [Command Line Interface Reference Guide for Cisco Unified Communications Solutions, Release 15 and SUs - Utils Commands](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/cli_ref/15/cucm_b_cli_reference_guide_release_15/cucm_b_cli_reference_guide_release_1401_chapter_01001.html), Utils Commands > utils diagnose test. Checked 2026-10-02.
[^58]: Cisco's 6.0 high-CPU technote advises that when IOWait is high and the CallManager service trace is set to Detailed, the trace level be changed to Error. Source: [Monitoring and Troubleshooting Cisco Unified Communications Manager 6.0 High CPU, using Real Time Monitoring Tool (RTMT)](https://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-callmanager/97086-ccm6-cpu.html), High IOWait troubleshooting steps. Checked 2026-10-02.
[^59]: The same 6.0 technote advises checking scheduled trace collection in Trace & Log Central during high IOWait and turning off the zip option if it is in use. Source: [Monitoring and Troubleshooting Cisco Unified Communications Manager 6.0 High CPU, using Real Time Monitoring Tool (RTMT)](https://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-callmanager/97086-ccm6-cpu.html), High IOWait troubleshooting steps. Checked 2026-10-02.