Re: Possible Threading problem with -CURRENT / MySQL?

Hi,

Please find answers below:

Regards
--
Lasse Laursen · VP, Hosting Technology · NetGroup Processing Aps
St. Kongensgade 40H · DK-1264 Copenhagen K, Denmark
Phone: +45 3370 1526 · Fax: +45 3313 0066

- Don't be fooled by cheap finnish imitations - BSD is the One True Code
----- Original Message ----- 
From: "Julian Elischer" <julian_at_elischer.org>
To: "Lasse Laursen" <laursen_at_netgroup.dk>
Cc: <freebsd-threads_at_freebsd.org>; <freebsd-current_at_freebsd.org>
Sent: Monday, June 14, 2004 8:15 PM
Subject: Re: Possible Threading problem with -CURRENT / MySQL?


> 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..

We have used FreeBSD on non-smp machines for a long time (even the 5.x
branch) without any problems. However on our new servers that are SMP the
problems occur. It's the exact same version of MySQL that runs on the
servers.

> the output of "ps -alxH might be useful.

I will post that the next time the machine locks up. :)

> 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

I will look into that as well - thanks for the promte reply.