Do not restart MySQL just like that. Usually it doesn't help at all -- the troublesome query or situation will come back sooner or later and after restart MySQL needs anyway to warm up. Restarting will flush its caches and so on.
What I suspect that is going on is that there is some kind of abnormal activity on your web site (such as DoS attack or Slashdot/Reddit effect), or perhaps a recent update included a new fancy database-killing bug. Check your http logs, or for more visual outlook, run the Apache logs through Webalizer or similar program.
If your problem is not due web activity or you would like to prevent problems like this in the future, typical situations for the spikiness you just described:
Non-optimally tuned my.cnf -- have you fine-tuned your InnoDB settings? Could we take a look at your my.cnf?
Missing indexes from some heavily used table.
Table type as MyISAM and then some long-running SELECTs combined with lots of UPDATE/INSERT/DELETE activity leads to huge query queues. This is actually what I think might be your problem: are you ABSOLUTELY sure your tables are in InnoDB format and this one table is not accidently (or even by purpose) in MyISAM?
Too small tmp_table_size value in my.cnf; this can be the situation if your database runs queries with lots of sorts, big results sets or similar. Too small tmp_table_size leads to situation where MySQL creates the tmp table it needs for the query to hard disk instead of storing it to RAM. For one query this is not essentially a bad thing, but if many queries are doing this at the same time, your hard disk performance will be a big bad bottleneck. This is another thing I suspect might your problem at the moment.
Databases are located on SAN or some other storage and for any reason the SAN itself slows down; maybe some other server is heavily using it.
Filesystem and/or I/O elevator is killing the performance. For example, if you have a typical Linux distribution, they are nowadays bundled with CFQ as the default I/O elevator. That might not be anywhere near optimal for database use - deadline or anticipatory are much better for that, I usually use deadline. I can guide you how to check out and/or change the current I/O elevator if you are in doubt - the operation is safe and can be done online. When it comes to filesystems, ext3 might not be the most performant one with huge database files, especially if concurrency is high.
And then some questions for you:
If it is InnoDB, what does SHOW GLOBAL INNODB STATUS tell you during the spikes?
Are the tables your web site needs to access huge? Are we talking about thousands of rows, millions of rows...? And storage-wise, do they consume lots of disk space?
What operating system you have in use? And what is the filesystem? Is the filesystem tuned at all? Are the databases lying on local disks or some kind of shared storage such as SAN?
You have 24 GB of memory, yes. But what does free report to you during spikes?
What kind of web site you run? Is it easily cacheable (such as a news site, where the content changes relatively rarely), or a Facebook-like über-dynamic site?
