Please help me out. My pbx keeps freezing such that I end up having to restart it to get things working again. When i check cpu usage, I notice that op_server.pl causes considerable load on the cpu. I have 17 channels, 35 extensions and I feel my cpu isnt able to cope with asterisk. I have 2GB ram and 3.6GHz processor, will this be sufficient to keep asterisk running properly? The pbx is being used for a call centre so phones are forever ringing.
I’m not too sure that op_server.pl is a script associated with Asterisk, if it is, it shouldn’t behvae like that. The machine you are mentioning seems to be sufficient for what you are doing.
Do you know where the op_server.pl file came from or what it does?
this script is for the server end of the “Flash Operator Panel” which is distributed with, among other things, trixbox. I have nothing good to say about it, either in terms of its utility or its performance.
The hardware that you have is more than adequate horse power to run the kind of configuration combination of lines and extensions you describe.
Below is the output I get when monitoring cpu usage, you’ll notice that asterisk shows 105% usage and op_server shows 17% but at times the op_server.pl can be as high as 41% or 67%:
The biggest problem with VOIP systems is very probably your system connectivity.
If you have a T1/E1 card in the system, it gives considerable work to the CPU. Even a small analog card can do the same thing.
Each channel has service needs (signally, audio sampling, packet routing, etc…) and each of these needs creates interrupts directed against the CPU. Sampling a channel will, alone, create eight thousand interrupts per second with certain cards using certain codecs.
Anything that monitors those channels will also create interrupts, as the CPU has to check the status, and send the information back to that process again and again to keep the process updated with the current channel status. (Further adding to the system overhead needs.)
If you have a great many channels in one server, it’s easy to overload a CPU just with the interrupt needs.
Having multiple cores doesn’t help, as each system process can report to one, and only one, processor.
The fix is usually re-engineering. Like spreading out the channels to multiple servers, using channel cards that have their own DSPs (so the processor doesn’t have to do the sampling itself) and/or using different codecs (so the system doesn’t have to translate the incoming/outgoing codec to something different).
Of course there could just be a bug in the process that you’re running that’s causing the problem too. You’ll have to spend some time with the system to determine the root cause of the problem.