More on MySQL -- Fatal trap 12

[Kris Gale]

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

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

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.

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

Kris Gale