Are your logs and data on the same partition? That's a bad idea for recovering from a blown part of the disk, but we also saw that one of our databases would crash when there were lots of inserts/updates/replaces -- other databases, which had the same version of MySQL and operating system, had the logs and data on a separate partition, and they did not crash.
We posited that there was just too much disk seeking going on, things would get slow, etc. -Sheeri On 3/30/06, Christopher A. Kantarjiev <[EMAIL PROTECTED]> wrote: > Mike Wexler wrote: > > It doesn't really answer your question, but have you tried "INSERT > > DELAYED" as a work around? > > We've not had a lot of luck with this in the past, but it's worth a try. > > > Also the "updated" status is strange, because that generally indicates > > that its looking for the record to be updated, but since the record is > > new, there is no record to be updated. Could it be checking for > > duplicates? Not that it should be this slow, but you might try ALTER > > TABLE xxx DISABLE KEYS and see how that effect performance. At least it > > will tell you whether the problem is in updating the keys, or something > > else. > > It's certainly checking for duplicates. There are 10034461 records in the > link_area table at the moment, and 514408715 in trimble.old_crumb. > > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
