<div dir="ltr"><div>Thanks for the feedback. </div><div><br></div><div>In this case SSD disks you think it solves?</div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><br>
</div></div><div>Eduardo</div>
<br><br><div class="gmail_quote">2014-07-23 18:01 GMT-03:00 Ron Wheeler <span dir="ltr"><<a href="mailto:rwheeler@artifact-software.com" target="_blank">rwheeler@artifact-software.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>I would also do some math on the
bandwidth requirement.<br>
<br>
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.<br>
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.<br>
<br>
What quality are you using in the recording? 44k per second(CD
quality sound) uses a lot more bandwidth than 3K (telephone
quality)<br>
What encoding are you using?<br>
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.<br>
<br>
If you disable recording, how many simultaneous calls can you
support? Just to be sure that recording is the issue.<br>
<br>
Ron<div><div><br>
<br>
On 23/07/2014 4:29 PM, Scott Griepentrog wrote:<br>
</div></div></div><div><div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_default" style="color:#660000">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.</div>
<div class="gmail_default" style="color:#660000"><br>
</div>
<div class="gmail_default" style="color:#660000">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.</div>
<div class="gmail_default" style="color:#660000"><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Jul 23, 2014 at 2:48 PM,
Eduardo Leones <span dir="ltr"><<a href="mailto:eduardo@ypytecnologia.com.br" target="_blank">eduardo@ypytecnologia.com.br</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>people </div>
<div><br>
</div>
<div>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). </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>tks</div>
<div>
<div dir="ltr"><br>
</div>
</div>
</div>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar
every Thurs:<br>
<a href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<img alt="Digium logo" src="https://my.digium.com/images/graphics/digium_RGB_signature.gif" style="color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif;font-size:12px" width="288" height="50">
<div>Scott Griepentrog<br>
Digium, Inc · Software Developer<br>
445 Jan Davis Drive NW · Huntsville, AL 35806 · US<br>
direct/fax: +1 256 428 6239 · mobile: +1 317 507 4029<br>
Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a>
· <a href="http://asterisk.org" target="_blank">http://asterisk.org</a><br>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</blockquote>
<br>
<br>
</div></div><span><font color="#888888"><pre cols="72">--
Ron Wheeler
President
Artifact Software Inc
email: <a href="mailto:rwheeler@artifact-software.com" target="_blank">rwheeler@artifact-software.com</a>
skype: ronaldmwheeler
phone: 866-970-2435, ext 102</pre>
</font></span></div>
<br>--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
<a href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br></blockquote></div><br></div></div>