More on MySQL -- Fatal trap 12

[Daniel Eischen]

On Wed, 18 Feb 2004, Kris Gale wrote:

> > I'm not sure what all the mumbo-jumbo is in your /etc/my.cnf,
> > but commenting out this line:
> >
> >   #set-variable    = key_buffer=1024M
> 
> This key buffer is shared amongst the threads.  This is the value
> I have set on an identical machine running -STABLE.
> 
> I'll do some testing today with this value set different ways, and
> try out KSE vs. libthr to see what happens.
> 
> Ideally, I need to get things running with this value quite large.
> Can anyone speculate as to why a big chunk of shared memory
> would slow down thread creation?  I don't know much about
> how threading works.

The library doesn't do anything with shared memory so it should
have no effect on it.

> > let your perl script run with 90 children w/20 connections per.
> > Everything seems to be running here, but I'm not sure what I'm
> > looking for.
> 
> Using my perl script, the problems I was describing would look
> like a huge scrolling mess of connect errors.  If it gets past the
> messages that say "Starting child..." and then starts to output
> the information on threads every few seconds, everything is
> running fine.

Yes, I got that when key_buffer was 1024M.  Are you sure you
want 1GB for this value?  What is the default value?

> A good experiment is to stop and restart MySQL while my perl
> script continues to run.  I will frequently see the kernel panics
> in this situation.  Assuming there is no panic, you'll see lots of
> connect errors for about 10 minutes (much less time with libthr),
> then eventually things will be fine.

I haven't tried starting and stopping mysql.

> >   set-variable    = thread_concurrency=1
> 
> The MySQL docs look like they're saying this only applies to
> Solaris.
> 
> >From http://www.mysql.com/doc/en/SHOW_VARIABLES.html :
>    thread_concurrency  On Solaris, mysqld will call
>    thr_setconcurrency() with this value.  thr_setconcurrency()
>    permits the application to give the threads system a hint for
>    the desired number of threads that should be run at the
>    same time.
> 
> It recommends setting it to number of CPUs * 2, which is why
> I had it at 4.

We do have a pthread_setconcurrency(), but it really only does
something if you try and lower the concurrency below kern.thread.virtual_cpu.
By default, the number of KSEs within the main KSEG is set
to kern.thread.virtual_cpu.  All process scope threads are
scheduled within the main KSEG -- having more than one
virtual_cpu (KSE) is like having a pool of system scope
thingies that can run all your process scope threads.

-- 
Dan Eischen