It appears that dialparties.agi is maxing out our processor on a regular basis and also causing server crashes on an almost daily basis. We are using a single PRI circuit which is regularly maxed out (23 channels). The problem gets MUCH worse when we use call monitoring (call recording).
Please help. This is killing us…
Thank you,
E
Well, we are not magicians nor mind readers.
Please provide us with some details about your install:
Sorry! Didn’t think to include that the first time. But here’s the data…
The version of FreePBX you are using.
2.6.0.0 – all modules are current
Are you using queues?
Yes, 15 of them.
How did you install FreePBX?
It comes with Elastix 1.5
Do you use a distribution such as AsteriskNOW, PBX in a Flash, trixbox?
Elastix 1.5
What version of Asterisk are you using?
1.4, I think.
Do you use Zaptel or DAHDI
DAHDI – Currently using 1 Rhino R1T1 card
Other info…
4GB memory, 2 hard drives: 80 Gb for core system and 250Gb for /var/spool/
2.8 GHz CPU
64-bit CentOS Linux
First, check that you are using the latest Asterisk and DAHDI.
Please read this thread: http://www.freepbx.org/forum/freepbx/users/queues-dialparties-agi-high-cpu-load
Next to try is a solution that worked for our company, however as it is a back port of code from Asterisk 1.6 to 1.4 it is not supported. I am just giving you a hint of how to ease the load of dialparties.agi.
Here it goes:
Look at this ticket http://www.freepbx.org/v2/ticket/3691, download the func_extstate.c from Asterisk, make the change as suggested in the ticket, do a make at the top of the Asterisk source tree. Copy the func_extstate.so to /usr/lib/asterisk/modules. Open up an Asterisk prompt do a module load func_extstate.so. Then do a bogus change in FreePBX extension to trigger the Apply changes button. Do that and Asterisk will use the func_extstate instead of dialparties when checking the state of an extension.
Note! It is an unsupported solution that have helped quite a few with queues problem. Please be aware that YMMV.
izrunas, While mickecarlsson’s solution may work, please bear in mind that FreePBX is not built to handel to many Queues with too many extensions. You didnt mention how many extensions your using, but having many extension p/queue + many queue’s is not something FreePBX will breeze right thru.
At present, we have the same 12 static members in 12 out of our 15 queues. The other three queues have 3-4 people each, also static agents. I simply cannot imagine that this is a “lot” of queues or agents–or am I wrong?
Apparently, the real challenge is going to be that we will be growing out to about 150 total extensions, 120 of which will be members of queues by the end of Q1 2010.
Are you telling me that FreePBX cannot handle such a normal size of company? If so, would you point me towards an alternate open source solution which will?
I’m sure we’re not the only ones wanting to do things like this–so this is a golden opportunity to tune FreePBX appropriately.
By the way, does it make a difference in performance between static and dynamic agents? Currently, we use static agents who go on system-level DND when they go on break or leave for the day.
Normal is a pretty ambiguous word. And yes, if you plan on having 150 extension in a queue with ring-all strategy, your in for some surprises.
While I haven’t tried it myself, it seems that a great part of the bottleneck can be avoided using mickecarlsson method. Why don’t you give that a try?
We use the “rrmemory” ring strategy–and if all agents are busy, we have it fail over (transfer) to an off-site answering service. Join when empty and leave when empty are both set to “strict”. Are these good settings to use for now (before I implement the mickecarlsson method)?
Also, how do I use the asterisk source when I am getting it via yum from the Elastix project?
rrmemory ensures that only one extension is called at a time. That means that the maximum number of simultaneous calls is limited by the max number of queues on your system. 12 is just fine. Perhaps mickecarlsson can kindly attach the compiled module?
mickecarlsson would be my HERO if he would be so kind as to attach the modified module I need (and I’m sure it would help others as well!)
Well, of course I can do that, BUT, it is dependent of what version of Asterisk you are using. It needs to be compiled against the correct version of the running Asterisk and if Elastix updates Asterisk via yum it will possible stop working,
Open up an Asterisk CLI prompt and type show version so that I know the exact version you are using.
Hmmm, I wonder if I (we) break GPL by supplying a compiled module
We’re currently running:
Asterisk 1.4.26.1 built by root @ rpmbuild64.elastix.palosanto.com on a x86_64 running Linux on 2009-08-24 21:53:53 UTC
We’re scheduled to deploy a new box over the weekend, might I trouble you for the 1.4.26.1-4 version as well?
Thank you. Thank you. Thank you.
This problem has been plaguing us for months and we need bullet proof vests (in the words of another user on here) to walk past the call center manager…
With the custom compiled module in place, is it still safe to upgrade both via yum and to go to FreePBX 2.7?
what custom compiled module?
There are numerous things in 2.7 and even more in 2.8 that can help with heavy Queue usage. However, the right solutions really depend on the specific environments.
Queues are a complex beast, the version that probably has the best options to address busy queues will be 2.8 though that is still in beta. There were some experimental capabilities added in 2.7 that need to be turned on through special settings in amportal.conf as well as required some back ported modules in Asterisk, however, some of the bugs in those portions of the code have had bug fixes in 2.8 that have not been rolled back to 2.7 (mainly the special case replacement of dialparties.agi with a new macro in some circumstances).
In order to stop the constant crashes of a server we manage with HEAVY queue usage, we got a custom compiled version of func_extstate.so to load into the server-- which did completely fix the crashing issue.
It’s safe to upgrade FreePBX. I don’t know what will happen if you upgrade the Asterisk RPMs with yum.
Worse case, I assume, you will have to re-install func_extstate.so manually so make sure you have it somewhere that won’t get removed by yum.
Eriks
I am using the same versions with a single PRI with heavy queues as you had.
With the same symptoms,And like you I think I need a bulletproof vest.
Is there any way you could help me with the custom compiled func_extstate.so you used?
Thank you