Database activity in RTMT

[Gordon Ross]

Since we upgraded from 8.0.2 to 8.0.3(SU2), we've noticed that RTMT is showing a lot more database activity ("Change Notification Requests Queued in DB") than before.

Has anyone else seen this ? CUCM appears to be working OK.

I'm half wondering if it's more a thing with RTMT changing how it counts these values.

GTG

[Jaime Valencia]

Queue Delay

This counter provides the number of seconds that the change notification  process has messages to process but is not processing them. This  condition is true if: •either Change Notification  Requests Queued in Database (QueuedRequestsInDB) and Change Notification  Requests Queued in Memory (QueuedRequestsInMemory) are non-zero, or

QueuedRequestsInDB

This counter represents the number of change notification records that  are in the DBCNQueue (Database Change Notification Queue) table via  direct TCP/IP connection (not queued in shared memory). This counter  refreshes every 15 seconds.

QueuedRequestsInMemory

This counter represents the number of change notification requests that  are queued in shared memory.

HTH

java

If this helps, please rate

www.cisco.com/go/pdihelpdesk

[Gordon Ross]

So what does it mean what those figures go negative ?

[tobin hawkshaw]

Bonjour mon ami

It may also be worth mentioning that this is a full sip installation. havn't got an answer for you but as long as they are not timing out then I would guess they have changed a timer or something between versions, your not using any new functionality on this version are you? presence or something similar?, or perhaps you have more services started than previously?

[Gordon Ross]

As I said: We've only moved from 8.0.2 to 8.0.3(SU2) - not a massive leap in versions. Certainly in the 72-hours since we've upgraded, I haven't rolled out any new features.

GTG

[Gordon Ross]

Finally found the root cause: Tomcat.

Had to restart Tomcat ('cause it was grinding to a halt, eating two cores of CPU useage)

After restarting it (it took a while to settle down, as Tomcat always does) DB activity & CPU useage dropped back to normal.