Mailing List Message #102795
From: Larry Ash <>
Subject: Re: Realtime subsystem overloaded
Date: Sat, 10 Dec 2011 10:45:22 -0700
To: CommuniGate Pro Discussions <>
X-Mailer: CommuniGate Pro WebUser v5.4.2
On Fri, 09 Dec 2011 13:38:12 +0400
 Technical Support <> wrote:


Thank you, This level of detail is VERY helpful for future debugging
of related issues.

On 2011-12-07 19:25, Tom Rymes wrote:
For some more information, I have changed the settings on the
Settings:Real-Time:Signals page to try and resolve this problem.

Processors: 10
Object Limit: 3000
Event Limit: 1000

Can anyone explain more clearly than the docs what these do and how one
might go about determining what settings to use?

The real time  part of CGPro uses four components: SIGNAL, SIP Server (SIPS), SIP Client (SIPC), NODE (also PBXLEG, CALLLEG). Each one is a collection of finite-state machines grouped in queues, where they all wait for events to change their state by processor threads.

When you see the "Realtime subsystem overloaded" message in the CGPro logs you need to note for which of four components it's reported. The problem may be as simple as the queue being too short (e.g. the number of simultaneous call setup attempts is higher than allocated queue capacity), or the number of processors is not enough to handle long queues or something else (processors are blocked - by disk IO, by DNS requests, by slow PBX applications).

SIPS and SIPC components are used with SIP protocol (including SIP-base IM clients). Requests received through SIPS transactions form SIGNAL objects which then can be relayed through SIPC transactions to SIP clients. SIGNAL objects may be created by other protocols (XIMSS, XMPP) and the server (CG/PL scripts, rule actions, alert actions) directly.
Optionally they can be processed by NODE (aka PBXLEG) objects (for IM that's common for multi-chat which in CGpro is implemented using CG/PL script that is processed as NODE-PBXLEG).

Note, that SIGNAL objects are created not only for IM or call setup requests. Lot's of SIGNAL objects are generated in the system to propagate notifications on changes of presence state.

So, the queue should be ready accomodate all those SIGNAL objects at any given time.
The limit on the events is more important for SIP environments when a SIGNAL object waiting in the queue may be changed (by a rule, redirecting to voicemail after some time, by a CANCEL requests etc.) The events queue limit may be 1-5% of the object queue length. The number of processors should be adequate to the expected rate of events: 1-10% of the events queue length.

For IM only environment I recommend to start with the queue length of 10000, the events limit 100-300 and the number of processors 3-5.
Then you may want to monitor the usage through SNMP statistics and adjust if necessary.


On 12/07/2011 9:42 AM, Tom Rymes wrote:
Hi all,

We have had some complaints of late where people complain that they send
IMs to other users but the other users does not get it. It seems
intermittent, and sometimes things are fine, and sometimes they are not.

I just noticed an error pop up on my client that stated "Realtime
subsystem overloaded", and I presume that this has something to do
with it!

Has anyone experienced a similar problem?


-- Best regards,
Dmitry Akindinov

When answering to letters sent to you by the staff, make
sure the original message you have received is included into your

This message is sent to you because you are subscribed to
 the mailing list <>.
To unsubscribe, E-mail to: <>
To switch to the DIGEST mode, E-mail to <>
To switch to the INDEX mode, E-mail to <>
Send administrative queries to  <>

Larry Ash
Network Administrator
Mountain West Telephone
123 W 1st St.
Casper, WY 82601
Office 307 233-8387
Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster