%UC_CALLMANAGER-2-TimerThreadSlowed

[fajar1224]

Hi All,

Is there any experts regarding this log %UC_CALLMANAGER-2-TimerThreadSlowed: %[AppID=Cisco CallManager][ClusterID=StandAloneCluster][NodeID=SUB01]: Timer thread has slowed beyond acceptable limits ?
Since there is little literature on internet.

This alarm occurs on idle time ( out of office hours ) and check to vmware, disk, cpu, network and memory still in normal usage

Thanks

[mradell]

The only explanation I've ever been able to find for this alert is from some of the older CUCM documentation, but it seems to apply:

Explanation   Verification of the Unified CM internal timing mechanism has slowed beyond acceptable limits. This generally indicates an increased load on the system or an internal anomaly.

Recommended Action   If this alarm occurs at the same general day or time, or if it occurs with increasing frequency, collect all system performance data in Real-Time Monitoring Tool as well as all trace information for the 30 minutes prior to the time that this alarm occurred and contact the Cisco Technical Assistance Center (TAC)

TLDR is it can happen due to high load. I have seen this alert in conjunction with high CPU usage on an 11.5 cluster. I suppose high memory, disk, or CPU utilization could cause it though. You may want to check your VM and/or RTMT for high utilization in these areas when it occurs and involve TAC if you have the support.

[fajar1224]

Hi mradell,

I've checked into cucm vm on esxi and everything is not in high load

[Sadav Ansari]

Its known bugs for 

Affected Releases

10.5(2.10000.5)

11.0(1.10000.10)

11.5(1.10000.6) 8.6(2)

9.1(2.10000.28)

check the below link for your reference.

https://quickview.cloudapps.cisco.com/quickview/bug/CSCty06667

Pls rate if its “Helpful”. If this answered your question pls click “Accept as Solution”.

[Adam Pawlowski]

There's a post in the Japanese community that refers to SIP OPTIONS from CUBE/gateway clobbering the thread. I implemented that fix by using groups to group up those requests. However, the UCM that was sending these messages just needed a restart and the messaging stop.

We couldn't pinpoint anything that was specifically causing it, though we could see it happening.