Buy or Renew
Buy or Renew
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
12704
Views
15
Helpful
2
Replies

Cmoninit high utilization issue

luiz.bianchini
Level 1
Level 1

‎10-20-2010 01:35 PM - edited ‎03-19-2019 01:46 AM

Guys,

I am experiencing an issue on the CUCM 5.1.3. Cmoninit is reaching 90% of utilization alone.

We tried to kill the process and reload the box, but, in few minutes the cmoninit processes get on the top again.

Do you know how to solve this issue?

Luiz Bianchini

Labels:
0 Helpful
2 Replies 2

Fernando Rivas Martin
Cisco Employee
Cisco Employee

‎10-21-2010 07:49 AM

Hello Luiz

cmoninit is the database process in the CUCM.

Usually when the cmoninit process is taking so much CPU and resources is related to another process making use of the database.

(It could be something wrong in the DB as well, but usually is another service using the DB).

- The fact that after reboot is also happening i would say then means that it is either some task still pending to be processed (BAT task, Backup, ...)

After the reboot how long it takes till you see the high CPU? Is it inmediate?

- Do you have any external server that access the CUCM via AXL/SOAP interface?

- How many servers do you have in the cluster?

Do you know if the replication is good in the cluster?

-Take Database Layer Monitor and Informix logs, we have to identify first what the database is doing, and eventually which process asked the database to do that.

Thanks
Fernando

srsivara
Cisco Employee
Cisco Employee
In response to Fernando Rivas Martin

‎10-21-2010 04:04 PM

Hey Luiz,


This is Sriram - we talked on the phone today to resolve this issue.


Just to close this thread out, we found that this is a known defect :


http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsv47100


the root cause is that CAR Scheduler goes into a loop trying to create a fragment with servers running the DST in South American time zone
 
Snippet of CAR Scheduler loop :
-------------------------------
 
2010-10-20 16:18:55,527 DEBUG [DailyCdrLoad] services.FragmentManager - createTblPartition(): --> 
2010-10-20 16:18:55,528 DEBUG [DailyCdrLoad] services.FragmentManager - createTblPartition(): Creating BillingTable Partition
2010-10-20 16:18:55,537 DEBUG [DailyCdrLoad] services.FragmentManager - createTblPartition(): The Partition part_20101009 is already present
2010-10-20 16:18:55,538 DEBUG [DailyCdrLoad] services.FragmentManager - createTblPartition(): Run [UPDATE STATISTICS FOR PROCEDURE]
2010-10-20 16:18:55,977 DEBUG [DailyCdrLoad] services.FragmentManager - createTblPartition(): Creating ErrorTablePartition
2010-10-20 16:18:55,982 DEBUG [DailyCdrLoad] services.FragmentManager - createTblPartition(): The Partition part_20101009 is already present
2010-10-20 16:18:55,983 DEBUG [DailyCdrLoad] services.FragmentManager - createTblPartition(): Run [UPDATE STATISTICS FOR PROCEDURE]
2010-10-20 16:18:56,768 DEBUG [DailyCdrLoad] services.FragmentManager - createTblPartition(): <-- 
 
These constant fragment creation attempts on the database results in the database service (cmoninit) spike.

Stopping CAR Scheduler network service on the Pub will reduce the CPU spike.

upgrading to  an  5.1.3 ES  will fix the issue.

- Sriram
Customers Also Viewed These Support Documents