Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Jun 2004 11:15:34 -0700 (PDT)
From:      Julian Elischer <julian@elischer.org>
To:        Lasse Laursen <laursen@netgroup.dk>
Cc:        freebsd-threads@freebsd.org
Subject:   Re: Possible Threading problem with -CURRENT / MySQL?
Message-ID:  <Pine.BSF.4.21.0406141107440.30464-100000@InterJet.elischer.org>
In-Reply-To: <01c301c45239$940781f0$6401a8c0@animal>

next in thread | previous in thread | raw e-mail | index | archive | help


On Mon, 14 Jun 2004, Lasse Laursen wrote:

> 
> MySQL 4.0.20 was compiled with --without-libwrap (libwrapper seems to be
> broken) and WITH_PROC_SCOPE_PTH set to yes.
> 
> WE use the SCHED_ULE, and:
> 
> # Memory options
> options         MAXDSIZ="(1536*1024*1024)"
> options         MAXSSIZ="(1024*1024*1024)"
> options         DFLDSIZ="(1536*1024*1024)"
> 
> The server runs fine until a single thread/query suddenly locks up the
> entire MySQL daemon. After that all queries are just queued and a restart of
> the daemon is needed to unlock the system. The system itself is stable
> enough as far as I can see. 'top' reports a lot of locks (*Giant) so I
> assume that it's some weird problem with the threading? We used to use
> FreeBSD on non-SMP machines without any problems.
> 
> I have tried with linux threads as well but the same problem occurs.

This does suggest a bug in MySQL, but let's investigate anyhow..


> 
> Have anyone experienced any similar problems and found a solution to this
> rather weird problem?
> 
> Feel free to request any further information about the system/setup and I
> will do my best to provide it to the list.

the output of "ps -alxH might be useful.

also:
 do you have teh kernel debugger compiled into the kernel?
(option DDB)

if so..
note the PID of the process
sysctl debug.enter_debugger=ddb
[you are now in the debugger]
ps
[note the Thread address of the threads that seem to be blocking things]
(I may ask for specific threads after seeing the 'ps' output)
do 

show thread {address}

to get a stack backtrace of those threads.

if possible use a serial console to do all this.. That way you can log
it all.

to make a serial console, connect 2 machines com1 by a null-modem cable.

on the other machine do:
script
tip com1

on the SQL machine add
console="comconsole"
into /boot/loader.conf and reboot

all console out put from teh boot-loader-on will now go to teh serial
port and appear in teh 'tip' output. (which is being logged by the
'script' command).

 julian





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0406141107440.30464-100000>