borked

I would tell your programmer to go and optimise the sql queries and tables. If mysql is constantly maxing out cpu on your current config, then there's something wrong. If the cause for this hogging is pretty much table reads, you need to start doing some table archiving so mysql can use the cache for the majority.

For example, I've a mysql dbase with 16 tables where one contains over 6 million rows, and another 1.2 million rows. The webserver mainly does db writes, which causes no spikes at all. When the db is being read, it's to pull out stuff based on days/weeks/months etc. Turn the mysql cache off and the server cpu is hogged by mysql. So, anything < today is archived, as this is never going to change by the db writes. Hence db reads for anything < today either use the cache, or very well optimised keys. This means I can hit mysql with a ton of reads and never hog more than 1% cpu. DB reads on "today" still caused big spikes, so all I did was inactivate reads on "today" and roll the website to be 1 day out-of-date. To the user, it doesn't make any difference, as yesterday's data becomes today's data, and they're none the wiser - all relative.

Like I said, dunno what you're doing, but you've gotta be able to hone your sql script somehow so as to not hog cpu like that on your current setup.... mysql optimisation isn't trivial, but it's always possible to keep on tweaking to shave a few cpu cycles.

__________________

For coding work - hit me up on andy // borkedcoder // com
(consider figuring out the email as test #1)