UCCX 7 Heap Memory Usage Exceeded Error

Unanswered Question
Dec 10th, 2009
User Badges:

UCCX 7.0.(1) SR5

Getting the following error when updating or adding new script applications:

"It is not recommended to update the application as Engine heap memory usage exceeded configured threshold. Click OK to continue and Cancel to exit."

Apparently this is an alert that was built into SR4 and is configurable under the System Parameters.

Does anyone have information on what processes use the heap memory in UCCX or how to monitor the usage?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.6 (5 ratings)
marknigh1 Fri, 02/19/2010 - 19:57
User Badges:

I received this message tonight for the first time on a 7.0 sr4 server. This is something to worry about?

Jonathan Schulenberg Fri, 02/19/2010 - 21:28
User Badges:
  • Super Bronze, 10000 points or more
  • Cisco Designated VIP,

    2017 IP Telephony

As Tom can attest to by now, this is something of an iceberg with big sharp edges below the surface.

The Java heap is fixed at 256MB on CCX. The Java heap is used by Tomcat as execution memory. In addition to this, applications, scripts, and other repository data is loaded into the heap at runtime. Depending on your environment, you may be approaching the limits of the heap, which cannot be changed. If the heap size is reached, it will be dumped and impact calls.

What have you been doing as of late on your CCX server? How many applications and scripts do you have? Are any of these using XML files extensively?

Note there is also a possible bug where the MIVR engine does not properly release all objects loaded into the heap at the end of a script execution leading to a memory leak of sorts. The discussion [debate] over this behavior is continuing. As of this week, it may be represented under /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman","serif";} CSCte49231. If it is, this may qualify as the most poorly described defect ever.

marknigh1 Tue, 02/23/2010 - 06:36
User Badges:

We went live on the system (testing was pretty extensive) on Friday, 2/19. The contact  center is about 35 queues/skills, about 60 agents logged in a given time. I do have an xml "read" at the beginning of the scripts to receiving about 4 variables (i.e. forced open/closed, voicemail on/off, etc.).

The big difference with these scripts compared with many I have done in the past is that all their DNISs point to a single script. This script does a database dip into an Oracle database with the dnis and the DB returns to me what "call center" to send the call (via subflows). I am concern with the number of subflows since I typically dont do subflow mostly because it is difficult to debug.

Interesting note, I received this message on Friday night (they received 1000 calls on Friday). On Monday (they received 2,200 calls), the message was gone.

chris.warren Tue, 02/23/2010 - 06:51
User Badges:

TAC stated that they have filed this under a new bug, but I don't know if the ID has been released yet.

marknigh1 Tue, 02/23/2010 - 07:04
User Badges:

So it is not cosmetic? It is something I need to be concern with? Should I reboot the server?

The interesting thing is that I got the message on Friday but yesterday I refreshed the applicationa and I didn't get the message.

chris.warren Tue, 02/23/2010 - 07:15
User Badges:

setup a perfmon counter and add the following counters. Java Process>Private Bytes and Java Process>Heap Bytes. If your Private Bytes exceed 153 (60%), you will receive this warning. It will go away once the memory is cleared, that is why you only see it during certain times.

The main thing to look for is auto-generated .hprof files in the MIVR log directory. This would indicate an issue.

Steven Pawlak Fri, 06/08/2012 - 12:14
User Badges:

I know this is 2 years old, but I am guessing that you might not have closed all the DB connections properly. I had a customer get this every day during peak volume. I went through the scripts and properly closed all the DB Get and DB Write steps. The occurance went way down. They also have just a lot of scripts.

Also, too many big XML files and too many scripts do this would be bad for heap.


This Discussion