[asterisk-users] Limit Asterisk

[Eduardo Leones]

Thanks for the feedback.

In this case SSD disks you think it solves?


Eduardo


2014-07-23 18:01 GMT-03:00 Ron Wheeler <rwheeler at artifact-software.com>:

>  I would also do some math on the bandwidth requirement.
>
> If you divide your disk bandwidth by your recording bit rate what is the
> theoretical maximum number of calls that you can record at once? Assumes
> that you have infinite CPU and memory and that you can actually drive the
> disks at their maximum.
> If this comes out to 300, you are already there. If it comes out to 3000,
> you have something wrong in your setup or your assumptions and a target to
> work towards.
>
> What quality are you using in the recording? 44k per second(CD quality
> sound)  uses a lot more bandwidth than 3K (telephone quality)
> What encoding are you using?
> How low a bit rate can you use and still have usable recordings? If they
> are for legal or audit use, you can go pretty low. If you are recording
> soundtracks for reuse in training or publication, you may require higher
> bit rates.
>
> If you disable recording, how many simultaneous calls can you support?
> Just to be sure that recording is the issue.
>
> Ron
>
>
> On 23/07/2014 4:29 PM, Scott Griepentrog wrote:
>
>  Your bottleneck is most likely your drive bandwidth.  Even with SAS
> drives, you'll need to move to a raid 5+ solution with 6+ drives to
> continue to increase the concurrent calls, or use a storage appliance.
>
>  To confirm this, install the tool nmon and use the v and d options to
> bring up the resource usage indicators and drive busy/throughput statistics.
>
>
>
> On Wed, Jul 23, 2014 at 2:48 PM, Eduardo Leones <
> eduardo at ypytecnologia.com.br> wrote:
>
>>  people
>>
>>  I have a running Asterisk 1.8.28 in great Dell server with two xeon
>> processors and 16gb of ram and HD SAS 15k (Raid 1). This server is
>> recording all calls (placed to record the audio in a ram disk), the entire
>> CDR goes straight to MySQL by cdr_mysql.so. Each call runs some validation
>> and AGI's have an auto dialer system that generates calls over the manager.
>> Calls originate and terminate via SIP (no transcode).
>>
>>  With this structure, even being a great server, we can not spend 150
>> simultaneous calls. When it reaches 140, the load average goes up a lot and
>> the calls start to get very bad audio, tear, etc.. Using the top we see
>> that all the processing is for asterisk. In this scenario, I think there is
>> some limitation in Asterisk, or even the manager due to the auto dialer.
>>
>>  Can anyone give me any tips where I can look where is the bottleneck? I
>> need to get at least 250 calls that server quality.
>>
>>  tks
>>
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>> New to Asterisk? Join us for a live introductory webinar every Thurs:
>>                http://www.asterisk.org/hello
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>
>
>
>  --
>  [image: Digium logo]
> Scott Griepentrog
> Digium, Inc · Software Developer
> 445 Jan Davis Drive NW · Huntsville, AL 35806 · US
> direct/fax: +1 256 428 6239 · mobile: +1 317 507 4029
> Check us out at: http://digium.com · http://asterisk.org
>
>
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler at artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>                http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20140723/8e33725b/attachment.html>