Best Xserve configuration for MySQL?

Question

Basically, I'm trying to figure out the optimal configuration for our next Xserve. Obviously, more RAM, more CPUs, more and faster disks in RAID, etc will improve things. But considering that money doesn't grow on trees, what have some of you found to be particularly cost-efficient in building an Xserve to run mainly MySQL where there are many small INSERTs on indexed (!? tables of 10 million or more rows (DB size of ~1GB, presently). I realize it's kind of a "depends if" type of question, but I'm just curious what people have found. (I've also read that AnandTech article that wasn't too kind to Mach.)
Anyway, I was thinking of an quad-core Xserve with 4-8GB of RAM, and a RAID5 set of 15K SAS drives. Well, there's not much in terms of options anyway. But this box will be like I said 90% running services that depend on MySQL performance. Some Web services, but mainly automated MySQL stuff.
Should I even bother to look at a Sun or Dell running Linux?
I'm presently running primarily an Xserve dual G5 2GHZ with MegaRAID in RAID5. As I said, the key database is about 1GB with ~10 million rows (mostly in just two tables). So, small data sets, already heavily indexed... Anyway, any thoughts are very welcome. Here is a status snapshot of the past couple days:
Traffic ø per hour
Received 1,168 MiB 21 MiB
Sent 1,631 MiB 29 MiB
Total 2,799 MiB 49 MiB
Connections ø per hour %
max. concurrent connections 92 --- ---
Failed attempts 0 0.00 0.00%
Aborted 81 1.43 0.08%
Total 98 k 1,731.89 100.00%
Total ø per hour ø per minute ø per second
6,409 k 113.27 k 1.89 k 31.46
Query type ø per hour %
admin commands 41 0.00 k 0.00%
alter db 0 0.00 0.00%
alter table 7 0.00 k 0.00%
analyze 3 0.00 k 0.00%
backup table 0 0.00 0.00%
begin 0 0.00 0.00%
call procedure 0 0.00 0.00%
change db 98 k 1,734.77 1.56%
change master 0 0.00 0.00%
check 0 0.00 0.00%
checksum 0 0.00 0.00%
commit 0 0.00 0.00%
create db 0 0.00 0.00%
create function 0 0.00 0.00%
create index 0 0.00 0.00%
create table 1 0.00 k 0.00%
create user 0 0.00 0.00%
delete 210 3.71 0.00%
delete multi 0 0.00 0.00%
do 0 0.00 0.00%
drop db 0 0.00 0.00%
drop function 0 0.00 0.00%
drop index 0 0.00 0.00%
drop table 1 0.00 k 0.00%
drop user 0 0.00 0.00%
flush 0 0.00 0.00%
grant 0 0.00 0.00%
ha close 0 0.00 0.00%
ha open 0 0.00 0.00%
ha read 0 0.00 0.00%
help 0 0.00 0.00%
insert 214 k 3,776.04 3.39%
insert select 5,725 101.18 0.09%
kill 6 0.00 k 0.00%
load 0 0.00 0.00%
load master data 0 0.00 0.00%
load master table 0 0.00 0.00%
lock tables 16 0.00 k 0.00%
optimize 0 0.00 0.00%
preload keys 0 0.00 0.00%
purge 0 0.00 0.00%
purge before date 0 0.00 0.00%
rename table 0 0.00 0.00%
repair 0 0.00 0.00%
replace 0 0.00 0.00%
replace select 0 0.00 0.00%
reset 0 0.00 0.00%
restore table 0 0.00 0.00%
revoke 0 0.00 0.00%
revoke all 0 0.00 0.00%
Query type ø per hour %
rollback 0 0.00 0.00%
savepoint 0 0.00 0.00%
select 941 k 16.64 k 14.92%
set option 855 15.11 0.01%
show binlog events 1 0.00 k 0.00%
show binlogs 43 0.00 k 0.00%
show charsets 121 2.14 0.00%
show collations 121 2.14 0.00%
show column types 0 0.00 0.00%
show create db 15 0.00 k 0.00%
show create table 376 6.64 0.01%
show databases 129 2.28 0.00%
show errors 0 0.00 0.00%
show fields 675 11.93 0.01%
show grants 46 0.00 k 0.00%
show innodb status 393 6.95 0.01%
show keys 37 0.00 k 0.00%
show logs 0 0.00 0.00%
show master status 0 0.00 0.00%
show ndb status 0 0.00 0.00%
show new master 0 0.00 0.00%
show open tables 1 0.00 k 0.00%
show privileges 0 0.00 0.00%
show processlist 18 0.00 k 0.00%
show slave hosts 0 0.00 0.00%
show slave status 0 0.00 0.00%
show status 415 7.33 0.01%
show storage engines 8 0.00 k 0.00%
show tables 186 3.29 0.00%
show triggers 0 0.00 0.00%
show variables 283 5.00 0.00%
show warnings 0 0.00 0.00%
slave start 0 0.00 0.00%
slave stop 0 0.00 0.00%
stmt close 0 0.00 0.00%
stmt execute 0 0.00 0.00%
stmt fetch 0 0.00 0.00%
stmt prepare 0 0.00 0.00%
stmt reset 0 0.00 0.00%
stmt send long data 0 0.00 0.00%
truncate 0 0.00 0.00%
unlock tables 16 0.00 k 0.00%
update 260 k 4,600.62 4.12%
update multi 0 0.00 0.00%
xa commit 0 0.00 0.00%
xa end 0 0.00 0.00%
xa prepare 0 0.00 0.00%
xa recover 0 0.00 0.00%
xa rollback 0 0.00 0.00%
xa start 0 0.00 0.00%
Begin
Variable Value Description
Flush_commands 1 The number of executed FLUSH statements.
Lastquerycost 0 The total cost of the last compiled query as computed by the query optimizer. Useful for comparing the cost of different query plans for the same query. The default value of 0 means that no query has been compiled yet.
Slow_queries 338 The number of queries that have taken more than longquerytime seconds.

Answer 1

RAID 5 is the worst possible storage option for databases.
That's not to say it won't work, but it has an overhead that will impact disk I/O, especially writes and it sounds like your data set is write-heavy.
This is because a write requires a Read-Modify-Write process for every write - whenever you write data to the array it has to read all the existing data in the corresponding blocks, recalculate the new parity data, then write it all back.
This may or may not be a problem for you, depending on actual quantity and scale of the writes, but if you're looking for the best configuration, RAID 5 is not it.
For optimal performance use RAID 0. Of course, RAID 0 has no protection, so you need to deal with that.
The ideal combination is RAID 0+1, but that requires a minimum of four drives, while the XServe can only handle three internal drives.
As for the rest of it, you really need to analyze your data more before you can get an answer.
The number of rows is largely irrelevant if you're just inserting data. It has some bearing on indexes, so you need to look at how your data is indexed.
As for memory, the ideal configuration is at least enough memory for MySQL to load all the indexes into RAM - most lookups should be indexed and if those indexes fit entirely within the memory space you're off to a good start.
Note that the standard MySQL is 32-bit, so you're limited to 2GB for InnoDB or MyISAM (whichever you're using). You'll need the 64-bit version to use more memory than that.
Most performance bottlenecks (and gains) can be traced to either indexes (too many indexes can be just as bad as not enough), and application (there's significant overhead in opening a new MySQL connection (which is a large factor in the AnandTech article), so try to ensure that your application uses connection pools (where a number of connections are opened when the app starts, and reused through application processes rather that a new connection opened for every query). Without knowing the application it's impossible to narrow that one down much more.
As for Sun or Dell - sure, they're options. Just be aware that you'll need Solaris or Linux admin skills in order to get the most out of them. They may (but not necessarily will) perform faster at the end of the day, but it may also take you much time and heartache to get there.
The other thing that you don't mention is why you're looking to upgrade. Is the G5 currently stressed? If so, where? what's the typical CPU load? disk activity level? network load, etc.
It doesn't make any sense upgrading the machine if the network is your bottleneck - all you're going to do is move that same bottleneck to a different machine.