My example of heavy load where mysql could not even begin to handle the situation was a project with real time stock market data streamed in as bids and offers and trades happened, statistics computed from that in real time, database kept in sync live, and charts and graphs plotted in real time for users on the site. Now that situation had more than its share of inserts and updates, and a massive wad of historical data being kept just to add to the fun.
Might I add for record that postgres did just fine.
At 02:56 PM 5/28/2003 -0500, you wrote:
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 <[EMAIL PROTECTED]>
_______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
