Yes. There was a query that locked a table and everything filled up and went boom while waiting. Row locking will be nice some day... I think similar things have done this before looking back into the error log (an automatic repair table a few days ago caused the server to crash since it locked the table up). For us, we can change the max_connections to about 400 which might help it enough to prevent crashing in these cases. We can avoid long queries, but we will have to keep an eye on max_connections in case a table gets repaired. The same table keeps getting corrupted (once about every three weeks).

Don't tell me lxr doesn't cache results! Arg! No one seems to write code that scales well (save for mysql, of course, minus the table locking thing in MyISAM). That drive me nuts!

You know, we have a three level object caching system that uses MySQL blobs as the cache repository. We were able to reduce the number of queries per second for a given amount of traffic by a factor of 50. MySQL's support for large blobs was the key to our using it in the beginning. BTW -- as a tip to others out there -- gzcompress serialized objects or large text messages before putting them in MySQL (and do it on the client side). It saves a lot of network traffic, disk size and accesses, and gives a great speed boost.

That was for 30 minutes at non-peak time. It does better than that actually. And it does it at a load of less than one all day on cheap 1999 hardware. We have more brain power here than cash, so we have to make do with what we got.

Sincerely,