There is known issue (apparently since FreePBX 2.5) where applying configuration changes through the FreePBX GUI can take up to 10 minutes (my own experience)!
According to this:
http://www.freepbx.org/trac/ticket/4435
This issue was scheduled to be fixed in 2.9. I have installed 2.9.0RC1.4, however, the problem only seems worse! Anyone have any ideas?
You need to provide more details.
How many extensions do you have?
How many trunks?
Voicemail enabled?
Is this a physical server?
How much ram do you have in the system?
CPU speed?
Our setup:
Physical server - Dell 2950 w/dual quad core (2.4Ghz)and 8GB RAM
Just about 1000 extensions configured, half of them with voicemail enabled
1 PRI + 8 analog lines on a single Sangoma card
Trixbox CE 2.8.0.4/Asterisk 1.6.0.26, with FreePBX upgraded to 2.9.0rc1.4
Centos 5.5
From what I can see (top, freepbx “status” dashboard), RAM, CPU, etc., are not being taxed.
Thanks for the response.
1000 Phones is a tremendous amount of dial plan to write out. Any time you reload the entire dial plan is generated.
This is close to one of the largest FreePBX installations I am aware of.
I am sure other people will have an opinion however I think this is very close to the limits of the current architecture.
Scott
I should add that a reload from the CLI takes < 10 secs. But when done from the GUI, then it’s 10 minutes.
-John
I presume you are talking about a reload from the Asterisk CLI?
That is completely different. As I pointed out FreePBX has to parse and rewrite every line of the dial plan when you commit changes.
The problem appears to be entirely in retrieve_conf. The thing is, this is a known “fixed” issue (apparently since 2008. see http://www.freepbx.org/trac/ticket/4435). However, for some reason, FreePBX 2.9.0rc1.4 still exhibits the same problem.
Again, the function of retrieve_conf is to rewrite the entire dialplan from the SQL database. Certainly 4435 resulted in performance enhancements in the process, however 1000 extensions is simply beyond the design of the system.
You are pushing the limits in many areas. I would consider two or three servers and a common server for voice mail.
There seems to be some disagreement about that conclusion. The discussion leading up to 4435, held up a lot of hope (and apparently realized in some testing) of significant improvements to this function. I would have expected to see at least some improvement, but if anything it’s worse! How can I verify that the fix that 4435 represent is actually implemented in 2.9.0.rc1.4? Or perhaps some configuration error is negating this?
I have to agree with Skyking. That is a big system. When you do the reload with 1000 extensions, there are probably several hundred transactions that have to tale place. That is occurring while the box is trying to process calls from a huge number of users. I think statistics say that an a given telephone system at any time 1/6th of the users are active…Doing something on the phone, so in your case, there would be around 160 users on the phone system at any time. If my figures are a bit wrong, that’s because they go back to my old analog telephony days.
The main point is it looks like your system is doing sll it can…no matter what ticket 4435 did.
Bill/W5WAF
Bill - I appreciate you supporting my point, but I did want to clarify your numbers.
Depending on the complexity of his dial plan the retrieve could need to process 100,000 lines of dialplan plus the peer configs.
As far as the 1/6 number of calls he indicated he has a PRI card so this must be a very underused system with a 45:1 oversubscription. My bet would be a hotel or similar.
Gotcha!
See you in Cleveland!
BF
I would agree with this assessment EXCEPT that we have another (older) system with the same number of extensions, and that system “applies configuration” in < 30 secs. This system is running Trixbox CE 2.4 (Asterisk 1.4/Freepbx 2.2). It doesn’t seem logical that the architecture has become less capable with newer releases?
Btw, this issue arose when trying to migrate from Tribox 2.4 to 2.8 (thus the two systems).
`John
Check the size of your /etc/asterisk/extensions_additional.conf file.
I have seen this behavior on some systems that was badly configured. It was a combination of disk driver, php, apache and mysql configuration and memory.
You say that you use a Trixbox install (shudders), that is a 32-bit system, yet you have 8 Gb of ram.
I suspect that it is a combination of memory allocation for apache/php/mysql. Check the config files for those programs to see if you can tweak those.
The changes that you refer to in ticket 4435 are implemented, you can check it in /var/www/html/admin/libraries/php-asmanager.php
While you are at it, remove the trixbox spy program that resides in /var/adm/bin/recognition.pl (remove that file) and the trigger in /etc/cron.d/trixbox
The information sent are in /var/log/registry.log
extensions_additional.conf is a 1.6MB file. I’ve removed the files you recommended, though I’m not sure how they’re related. Can you clarify? I’ll look into the apache/php/mysql “tweaking”, but I’m not an expert on any of those, so that may take some time 
I inherited a Trixbox 2.4 system, and was asked to upgrade it to 2.8. It didn’t take long for me to realize that Trixbox maybe isn’t a great choice anymore (if it ever was). So now stuck with this issue, I’m seriously considering migrating to a new distro. So, I have a few questions?
Thanks for all the responses so far.
`John
If you are using FreePBX 2.9 and no other features of trixbox like endpoint manager and such you can do this:
Go to the backup module, Add a backup schedule, give it a name (NO spaces in name!), select CDR, System Recordings, Voicemail and System Configuration. In Run Backup you select Now and click on Submit Changes.
Go to /var/lib/asterisk/backups
In there you have a directory same as the backup name, go into that directory and copy the file therein to a safe place.
Install a new distro (hint: http://www.freepbx.org/news/2011-04-11/introduction-to-the-new-freepbx-distro)
Upgrade to the same version as you currently are running, with all modules that you have enabled. (VERY IMPORTANT)
Make a backup on the new system with the same parameters as above.
Go to /var/lib/asterisk/backups and into the directory, move that file in there to some other place and copy your previously backup file in there instead.
Go to the backup module and do a restore, you will see your backup, run it and you have restored your server.
Check so that all is there (voicemail and system recording).
I think that this will do the trick for you.
I’m about try these instructions, and want to make sure I understand. When doing the backup, it doesn’t seem that backing everything thing is being backed up. What happens to extensions, ring groups, ivrs, etc. with these backup instructions? Can these not also be migrated?
Thanks,
John
All of the FreePBX configuration is captured by the backup.
Do a backup, then restore it to a test server (use virtualbox or vmware workstation).
By doing that you can test it so that you minimize downtime.
By testing in a virtual environment you can also see if your problem with long reload is solved.
However, as pointed out earlier, 1000 extensions are a LOT of extensions.
Happy that you have it worked out. I was running into different issues, but similar (albeit on a much smaller scale) in that a current FreePBX system backup from an older PIAF install was causing issues when restored on the new FreePBX distro. Philippe did his best to answer the questions I had in another thread, but it seems that a full restore is a rather blunt instrument.
Luckily I had csv files to import the DID’s & extensions into the new system and rebuilt the rest. I was able to restore the vm and cdr, which was a high priority. It really didn’t take that long.