[Asterisk-Users] 2 4-port T1 cards

Steven Critchfield critch at basesys.com
Wed May 28 12:56:14 MST 2003


On Wed, 2003-05-28 at 14:36, Ron Gage wrote:
> On Wednesday 28 May 2003 02:30 pm, Steven Critchfield wrote:
> > On Wed, 2003-05-28 at 11:02, Joe Antkowiak wrote:
> > > 1.  Voicemail, and the voicemail itself will be stored on another box,
> > > NFS mounted, or I might use mysql.  There will be a little bit of call
> > > routing via iax to a separate * box with a channel bank on it.
> >
> > Don't use Mysql. if you ever have had to deal with it in a production
> > environment that works it over, you will know that as it reaches it's
> > limits, it starts a death spiral that is very difficult to recover from.
> > For our software on a dual P3 866 with a gig of ram, the limit was
> > around 1.5 queries a second fairly mixed update, inserts, and selects.
> > Total file size of the database was under 200meg, and was fully cached
> > so even though we had hardware raid 5 across 4 10K rpm ultra160 drives,
> > it shouldn't have mattered for the selects.
> 
> Um...
> 
> I suppose that if MySQL can't handle more than 1.5 operations a second, 
> someone should tell the folks at Slashdot and Yahoo that their choice of a DB 
> engine isn't going to scale too well.

See other post about why Slashdot isn't a good argument here. 

It applies equally well for Yahoo. They both are select heavy, and Mysql
is able to parallelize these just fine. I also doubt Yahoo does it's
updates to the production databases, they probably do it to a backend
that then gets replicated to multiple less backends that do the real
serving of data. 

> For that matter, I suppose that GIS database I have here (the entire Tiger 
> census data for the state of Michigan - 1.2 million type A records alone) 
> isn't capable of handling more than 1.5 transactions a second.  So, when I 
> generate an AutoCAD script from the database records (generates a full-scale 
> road map of the entire state of Michigan), it shouldn't be capable of running 
> in under 10 minutes (at 1.5 transactions a second, it would take 13,333 
> minutes to run the script).

Thats great for a single user. Now put 30 processes doing random updates
and inserts while 5 users try and generate that map.

> I would strongly suggest that something is seriously messed up with your MySQL 
> implementation if you are only capable of getting 1.5 transactions a second 
> before the "spiral of death".
> 
> For comparison, I am running Mysql 4.0.12 on Slackware 9.0.  AMD XP1800, 1 gig 
> memory, single 73 gig SCSI-Wide drive, Adaptec 29160 controller.  It can do a 
> select distinct across the 1.2 million records in under 4 seconds.

Again, 1 user on decent hardware, whoopeee. Try scaling that out and
watch it die. 
-- 
Steven Critchfield  <critch at basesys.com>




More information about the asterisk-users mailing list