Whether SSD drives allow you to add any additional calls depends entirely
on whether or not they can be written to faster than the SAS drives you
have. My experience shows SSD's can be twice as fast as run-of-the-mill
SATA, but the performance difference compared to SAS is likely not as
great,
Thank you all for the answers. I will do tests to find the problem.
One other question I have, in the scenario that I sent, how bad would be to
transcode G711 to G729 in 70% of calls? There is a study that shows a
statistically loss of performance (concurrent calls) with active transcode?
tks
Another question, what audio format I use in MixMonitor to maintain a
connection with reasonable quality and reduce the use of I / O disk? Today
I use wav.
tks
2014-07-24 9:05 GMT-03:00 Eduardo Leones edua...@ypytecnologia.com.br:
Thank you all for the answers. I will do tests to find the
Please don't top-post.
Please trim irrelevant posts.
On Thu, 24 Jul 2014, Eduardo Leones wrote:
Another question, what audio format I use in MixMonitor to maintain a
connection with reasonable quality and reduce the use of I / O disk?
I think the question is premature.
You have a resource
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
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
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
Thanks for the feedback.
In this case SSD disks you think it solves?
Eduardo
2014-07-23 18:01 GMT-03:00 Ron Wheeler rwhee...@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
Thanks for the feedback.
In this case SSD disks you think it solves?
2014-07-23 17:29 GMT-03:00 Scott Griepentrog sgriepent...@digium.com:
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
Do the calculations for both and see what the answer is.
The nice thing about having a model is that you can test configurations
without actually having to build one until you are confident that it
should work.
Ron
On 23/07/2014 5:04 PM, Eduardo Leones wrote:
Thanks for the feedback.
In
Please don't top-post.
On Wed, 23 Jul 2014, Eduardo Leones wrote:
In this case SSD disks you think it solves?
Don't buy hardware until you've identified (either empirical or
calculated) the bottleneck.
But...
SSDs do rock. I recently observed (via vmstat 5) a Samsung 840 topping out
at
On 23/7/14 10:29 pm, Steve Edwards wrote:
Don't buy hardware until you've identified (either empirical or
calculated) the bottleneck.
If you've plenty of spare RAM (and at 16GB I'd suggest you probably do),
I'd throw in the possibility of recording to RAM disk, then moving the
calls to hard
On Wed, 23 Jul 2014, Chris Bagnall wrote:
The 840 is a great bit of kit...
The 850 is supposed to be shipping next week. It's got 3d VNAND so the
chip geometry can be bigger -- higher speeds and greater reliability.
--
Thanks in advance,
13 matches
Mail list logo
