List:General Discussion« Previous MessageNext Message »
From:Rik Wasmus Date:May 25 2011 8:08am
Subject:Re: After long semaphore waits MySQL becomes unresponsive.
View as plain text  
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
Thread
After long semaphore waits MySQL becomes unresponsive.rik24 May
  • Re: After long semaphore waits MySQL becomes unresponsive.Johan De Meersman24 May
    • Re: After long semaphore waits MySQL becomes unresponsive.Rik Wasmus24 May
      • Re: After long semaphore waits MySQL becomes unresponsive.Johan De Meersman24 May
        • Re: After long semaphore waits MySQL becomes unresponsive.Rik Wasmus24 May
          • Re: After long semaphore waits MySQL becomes unresponsive.Johan De Meersman24 May
            • Re: After long semaphore waits MySQL becomes unresponsive.Rik Wasmus25 May
              • Re: After long semaphore waits MySQL becomes unresponsive.Johan De Meersman25 May
                • Re: After long semaphore waits MySQL becomes unresponsive.Rik Wasmus25 May
                  • Re: After long semaphore waits MySQL becomes unresponsive.Johan De Meersman25 May