On 2011-05-24 18:25:07 Johan De Meersman wrote: > > OK, but that would mean that the answer to the question: > > > > "I may be wrong here, but I tend to interpret this as > > '140054029002496' is trying to get an exclusive lock on 0x78733f8, on > > which it already has an exclusive lock, and hence is deadlocked in some > > manner" is 'no there is another query' (i.e.: it isn't locked on > > mistakingly acquiring a lock it already has) rather then 'that seems > > likely' :) > > Ah, misread that. Yes, the former behaviour seems more like a bug; which is > not entirely impossible of course.
Ack. > > And in my case, the server became unusable (kept running into > > semaphore locks at 769 seconds before a kill & start was given). Query > > timeouts / crashes I can live with, an unresponsive server I cannot... > Which is what kind of mystifies me - it should detect deadlocks as soon as > they happen. Well, usually it does :) > > OK, let's hope I never get to show that output (i.e: that the problem > > doesn't reoccur). Since the server has been restarted since-start > > counters will probably be pretty useless. > > Yups. A trending database (munin, cacti or something) may or may not offer > much hindsight in this case (mostly a matter of luck at when it last > checked); but it's definitely something useful to have at hand for plenty > of other purposes. Cacti does store a lot of things by snmp, that's the way I know memory, CPU usage & average load never showed a hitch, all's well according to the OS, only MySQL is slowly dying... > > Yup, right there it did, And that's the way I like it: kill the/a > > query, which issues an error somewhere else we know if and how to handle > > in some application, rather then letting a database server with a light > > load grind to a halt. > > > > My main problem at hand is why the server did nothing but seize up > > gracelessly, rather then either dying (a last resort, but something > > we have failovers for) or killing queries (which we can handle). > > Uhuh. You may want to take this to the mysql-dev mailinglist, the good > people there might have a bit more insight about the error runes you > posted. OK, will do, thanks for the help, maybe I'll also file a bug, seems something that should be fixed :) -- Rik Wasmus -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
