Jump to content

Theorhetical Maximum Reached?


ap_6200
 Share

Recommended Posts

I have a Feature Server set up with 19 domains and a total of 390 Accounts across those domains.

 

I am seeing a consistent day-time call volume of 15-25 concurrent calls using 2.1.4 until 2.1.5 can be further tested:

 

Calls: 11323/2587 (CDR: 4124) 20/38 Calls

SIP packet statistics: Tx: 2426674 Rx: 2326830

Emails: Successful sent: 438 Unsuccessful attempts: 122 (Warning: Last email could not be sent!)

Uptime: 3 03:13:36 (77MB/2047MB 20% 43010880-0) WAV cache: 3

 

The media CPU usage during the day is between 25% and 50%... Ususally coinciding with the Call Objects.. Meaning at this time - the utilization would be at 38% (based on the graph)

 

 

Have I reached the theorhetical maximum? Are there any other customers or forum-posters with this many domains/accounts - and concurrent calls?

 

Complaints are coming in referring to static, audio cut outs, etc...

 

Is 2.1.5 any better, or do I need to start moving customers off of this feature server?

 

Please advise!

Link to comment
Share on other sites

Is 2.1.5 any better, or do I need to start moving customers off of this feature server?

 

No, 2.1.5 is no difference regarding the performance.

 

My opinion is that hardware has become so cheap today that it is not worth having customers complaining about dropouts. So I would definitevely power up another server.

 

The new domain backup feature comes in handy. It should be relatively simple to move a few domains off to a new server!

Link to comment
Share on other sites

No, 2.1.5 is no difference regarding the performance.

 

My opinion is that hardware has become so cheap today that it is not worth having customers complaining about dropouts. So I would definitevely power up another server.

 

The new domain backup feature comes in handy. It should be relatively simple to move a few domains off to a new server!

 

 

So a thought could also be that the PBXnSIP software can't handle this load, as opposed to the hardware? We didn't buy cheap hardware - and have invested heavily.

 

Other suggestions?

Link to comment
Share on other sites

Well, there are other limitations like the number of sockets that you can have open. And the absolute maximum number of calls in 2.1 are 256 calls (2-legged). All other structures are pretty much dynamic.

 

But that all does not explain choppy audio. The CPU load meter is what we should pay attention to. Maybe the blue line at 75 % is still too optimistic and we should lower it to like 50 %.

Link to comment
Share on other sites

So a thought could also be that the PBXnSIP software can't handle this load, as opposed to the hardware? We didn't buy cheap hardware - and have invested heavily.

 

Other suggestions?

 

Linux or Win? What Version?

 

disk controllers might be heaviliy used causing interupts? Consider RAM drive from Gigabit for swap on linux or or Win.

 

In the Win system are you familiar with perfmon or system admin, WMI etc.

 

I can refer you to a Voip SIP call recorder, and you can with client permissions record all calls and confirm the drop outs, cracks etc exist on the NIC ports the Servers.

 

Perhaps it's the QOS,DIF stuff on the circuit?

 

when you said, "Invested heavily" Just what is this running on?

 

I know 23 concurrent calls for 5 or 6 hours straight across 45 extensions for 4 weeks in a row never raised a AMD3100 over 9% utilization on a WinXP Pro box with a NIC to a PRI gateway, a NIC to the LOCAL Lan, and a NIC to the public intenret.

 

2.1.5.2357 (Win32)

License Status: Office 75

License Duration: Permanent

Additional license information: Extensions: 58/75 Accounts: 78/100

Working Directory: C:\Program Files\pbxnsip\PBX

IP Addresses: 127.0.0.1 192.168.1.250 192.168.100.1 216.xxx.yyy.20

MAC Addresses: 1D04ACC519C4 1D15F29BC703 1D902713C720

Calls: 2917/486 (CDR: 6322) 0/0 Calls

SIP packet statistics: Tx: 3844156 Rx: 3844269

Emails: Successful sent: 31 Unsuccessful attempts: 5591 (Warning: Last email could not be sent!)

Uptime: 8 02:06:28 (51MB/511MB 54% 13842388--6078828) WAV cache: 0

Link to comment
Share on other sites

Complaints are coming in referring to static, audio cut outs, etc... Is 2.1.5 any better, or do I need to start moving customers off of this feature server? Please advise!

 

Can you share whats become of this situation? You can't sweep something like this under the rug with your clients.

Link to comment
Share on other sites

We upgraded to 2.1.5 and moved some domains off of this particular FS to load balance across the server farm.

 

This will give me a clear indication on Monday or Tuesday if indeed I have reached the upper echelon of active calls without affecting voice quality.

 

By no means am I happy with this solution, because I should be able to do more than what i'm able to do - but the limitations are there, and nobody from PBXnSIP has been able to offer me any other suggestions. I have 6 FS's for my customer base, all built identically.. The only one I'm having trouble with - is the one I described earlier.

 

I am not seeing any negative indication from the server itself - it is only the Media CPU Usage graphed in PBXnSIP.

Link to comment
Share on other sites

I have 6 FS's for my customer base, all built identically.. The only one I'm having trouble with - is the one I described earlier.

 

Hmm. We had a very strange case recently where the MTU was set to a short value which caused a lot of strange effects... It took a lot of time to find that problem, but in the end it was good to see why the "mystery" was not a mystery. Maybe it also makes sense to find out what is different on that specific server and once we find it out put it on the check list.

Link to comment
Share on other sites

By no means am I happy with this solution, I am not seeing any negative indication from the server itself - it is only the Media CPU Usage graphed in PBXnSIP.

 

Would you expand on the questions regarding your platform. If you'd like to do that off-line I think my profile will drop me a line.

 

Diagnosing this problem should be easy since it appears as if you can predict failure based upon load. So therefore the system should be working fine with a smaller load and we can track performance and isolate the failure to the extranet or the intranet and the place to start is to packet capture all data to the failing server during a low use (working OK) and into the (Not working OK) high use period.

Using a good quality Switch that supports port mirroring capture all traffic... I also know of a low cost software package that will record and rebuild in realtime all SIP/RTP sessions and record all calls.

This will give you something to go on, an until you can starting asking questions that can be answered you will be chasing ghosts...

 

Happy to help.

Link to comment
Share on other sites

  • 11 months later...

Don't rely on just those customer reports of audio dropping off to determine you are nearing your max CPU for PBXNSIP.

 

Get an IP phone plugged directly into the lan or WAN of the server.. try both.

 

During the busiest time of the day and during those types of loads test with a locally connected telephone and make calls into/out of voicemail.

If it's not choppy and sounds perfect in both directions (recorded messages) I'd bet you have plenty of CPU/RAM/IO to spare.

Also try PSTN calls if you have locally connected PSTN. (not distant voip).

 

Just my immediate thoughts..

Maybe you have already done these tests.

 

 

-Steve

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...