threads/136345: Recursive read rwlocks in thread A cause
deadlock with write lock in thread B
Nick Esborn
nick at desert.net
Thu Jul 16 17:51:01 UTC 2009
On Jul 16, 2009, at 5:48 AM, Attilio Rao wrote:
> 2009/7/16 Attilio Rao <attilio at freebsd.org>:
>> 2009/7/15 Nick Esborn <nick at desert.net>:
>>> The following reply was made to PR threads/136345; it has been
>>> noted by GNATS.
>>>
>>> From: Nick Esborn <nick at desert.net>
>>> To: bug-followup at FreeBSD.org,
>>> rink at FreeBSD.org
>>> Cc:
>>> Subject: Re: threads/136345: Recursive read rwlocks in thread A
>>> cause deadlock with write lock in thread B
>>> Date: Wed, 15 Jul 2009 14:32:38 -0700
>>>
>>> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
>>> --Apple-Mail-19-950902279
>>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>>> Content-Transfer-Encoding: 7bit
>>>
>>> Even after the above patch, I still run into occasional MySQL thread
>>> deadlocks, which I originally described in what is now threads/
>>> 135673.
>>>
>>> I also posted on freebsd-current a few days ago:
>>>
>>> http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009328.html
>>>
>>> I'd be happy to collect whatever data would be helpful in tracking
>>> down this deadlock. This only seems to happen under our production
>>> workload, so that might make it harder to capture meaningful debug
>>> data, but I'm certainly willing to try. I can also arrange for
>>> developer access to the system in question, if that would help
>>> significantly.
>>
>> So did you backport this to 7 and still experience deadlocks?
>> I just committed the fix to HEAD not to STABLE branch.
>
> Ok, I got, you just upgraded.
> Can you try the following things?:
> - Upgrade to the -CURRENT of today
> - Recompile the kernel with the following options:
> KDB, DDB, SCHED_ULE, PREEMPTION, FULL_PREEMPTION, INVARIANT_SUPPORT,
> INVARIANTS, WITNESS
> - When the deadlock takes place break into DDB and please retrieve the
> following info:
> db> show allpcpu
> db> ps
> db> alltrace
> db> show alllock
>
> - Save them with a serial console output or using the textdump(4)
> format.
>
> (if necessary read the ddb(4) and textdump(4) before to set up the
> whole system).
> This would shade a light if the problem lives within the kernel or
> not.
>
> Thanks,
> Attilio
>
>
> --
> Peace can only be achieved by understanding - A. Einstein
I can definitely do the upgrade.
KDB, DDB, SCHED_ULE, and PREEMPTION are already turned on. I will try
FULL_PREEMPTION, INVARIANT_SUPPORT, INVARIANTS, and WITNESS, but when
I first upgraded to 8.0, this server was unable to handle its workload
with the INVARIANTS and WITNESS options turned on.
Also, it can take a while for it to become clear that the deadlock has
occurred -- usually our monitoring picks it up when replication falls
behind. So it may be 15-20 minutes after the deadlock that I am able
to run the above db commands. Of course the thread will still be
deadlocked. Hopefully that doesn't reduce the value of the data
obtained.
Thanks,
-nick
--
nick at desert.net - all messages cryptographically signed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20090716/512bfdc6/PGP.pgp
More information about the freebsd-threads
mailing list