If you don't do nightly backups, then keep using the logs although I don't really like the idea of using them for that purpose.

The issue here is the same disk is shared between httpd and MySQL making it usage very high. If you move your MySQL data on another disk, the data will be served off that drive and it will split the I/O load between those two drives. I won't get on the hardware side and or formatting/mounting the disk, but once you have the second disk installed and mounted, you can move MySQL data to it using the article; How To: Move MySQL to a Second drive ..

Well, you have one advantage here, i.e. network. Data from same server is usually faster locally than on a network. Ofcourse, it doesn't implies it's a separate MySQL server, but the MySQL is using a separate disk to split the I/O load.

Actually we do nightly backups. Then do we really require the bin logging?
When does the bin logging come in handy other than for replication?

It isn't really needed if you do nightly backups ..

Oh god... It happened yesterday too... This time it was deadly....
See the attached mytop snapshot. How is this possible, queries taking 1500 seconds....
Also see the Apache status...

I m worried. Whats wrong?

Thanks,
Ratheesh

Make use of all what I had mentioned in my earlier posts and do the changes. It should help. The last resolution is to put less work on MySQL and rewrite your queries to drop things that let MySQL do the hard work and instead let the PHP do it. (esp. if MySQL needs to use temporary files for that job -- EXPLAIN's your friend)

It is possible for a query to take that long when you're under heavy load.