List:General Discussion« Previous MessageNext Message »
From:BD Date:April 4 2002 5:31pm
Subject:Re: Clustering MySQL was: Re: Best hardware for a very large
MySQL server? looking at x86
View as plain text  
At 10:28 AM 4/4/2002, you wrote:
>On Thursday 04 April 2002 09:48 am, you wrote:
> > I think you'll find that the RISC systems have fewer processors and run at
> > lower clockspeeds for the same total performance. 100k is a HUGE amount of
> > money to drop on a system. You could get 2 full racks of high performance
> > 1U systems, including everything, for less, but whatever!
>I forgot to ask... while I haven't looked, I've never seen anythign on
>clustering MySQL. I presume that it can be done since you said that, but has
>anyone here actually tried it? Is it better than one huge server?
>Our problem is we're dealing with some enourmous tables that our web servers
>are accessing. We currently have a PowerEdge 2450, 5disk RAID 5, Dual PIII
>850s, 2GB RAM and we are killing it - the load is too much.
>That's why our management decided to get a whopping big server - so it can
>handle the load.
>We're not done growing yet either...
>         JW

JW et al,
         Where is the bottleneck? How many concurrent users do you have? 
How many rows are their queries returning? I always slap a "LIMIT 100" on 
each query to prevent the user from retrieving too much data. If they don't 
like it, there is a query form that allows them to refine their query.  For 
non-registered users I limit them to 10 rows.

         How many webservers do you have and what are you running on them? 
PHP, ASP, JSP? If you are using PHP you can compile the PHP with Zend 
optimizer (I think that's what it is called). It will give you around a 50% 
performance increase on the webserver. PC Mag reviewed it a few months ago.

         Is your MySQL server disk bound? Does it have too much I/O for the 
drives to handle? If so, adding more processors won't solve the problem. It 
would probably only make the problem worse because it would put even more 
demand on the drives. There are (very expensive >$30,000) ram disks that 
may solve the I/O problem (it that is your problem). These are hardware RAM 
disks complete with onboard battery backup. It looks and acts just like a 
super fast hard disk. If you turn the server off (or it crashes) the data 
is still retained in RAM.  To the OS it looks like another hard disk.  I 
looked at them a couple of years ago and they were very expensive for the 
amount of RAM you get. Perhaps the prices have come down. But it would 
certainly speed up your data access.

         Are people accessing your database as read-only? If so, 
replicating the data to several servers will be relatively easy. I assume 
if there are a lot of users writing to the tables, you've eliminated the 
table locking problem by trying InnoDb.

         And of course the first thing you should look at is optimizing the 
SQL you're using to access the database.  You could have inefficient code. 
Contract someone at MySQL AB to look over the code to see how it can be 
optimized. It could be money well spent.

         And if you've just won the lottery or your client has some deep 
pockets, there is also the IBM zSeries mainframes that run multiple Linux 
machines. I believe it supports up to 512 processors and 64 gb of RAM.  It 
will run hundreds of Linux sessions independently or in a parallel 
cluster.  You only buy what you need ($500 per Linux image) and expand 
later.  You can also use it 
to heat your building during the winter.<g>


Do You Yahoo!?
Get your free address at

Clustering MySQL was: Re: Best hardware for a very large MySQL server? looking at x86JW4 Apr
  • Re: Clustering MySQL was: Re: Best hardware for a very largeMySQL server? looking at x86BD4 Apr
    • RE: Clustering MySQL was: Re: Best hardware for a very large MySQL server? looking at x86Basil Hussain5 Apr