More on MySQL -- Fatal trap 12

[Daniel Eischen]

On Tue, 17 Feb 2004, Kris Gale wrote:

> >> What I seem to be seeing is a bogging down of MySQL
> >> when new threads are being created in bursts.  This
> >> causes MySQL to temporarily become unresponsive,
> >> and will sometimes crash the whole system.
> >
> > My  first question is:
> > "In what state are these threads waiting for work?
> > are they in the kernel, or are they in userland?
> > is there a single thread that listens on a socket and then hands the
> > work to worker threads using some userland synchronisation, or do the
> > threads enter the kernel and wait on the sockets themselves?
> > (i.e. what does ps -H show?) "
> 
> I'm not really sure how to answer this.  During the startup
> of my test script, when I'm seeing all of the connect errors,
> "ps auxwH" shows a growing number of mysqld threads.
> All but one have "SL" listed in the STAT column.  The other
> one has "RL" listed.
> 
> > what happens if you have 1 process with X*Y threads?
> > (just curious).
> 
> No problems.  1800 threads run fine.  The problem
> seems to be with the child processes trying to initialize
> connections simultaneously.  I can also "solve" the
> problem by putting a sleep in so the child processes
> aren't forked at the same time.  However, this is
> not a workable real-world solution, since the application
> I'm trying to simulate is a theoretical burst of connections
> from a web cluster.

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

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.

Hmm, I also set:

  set-variable    = thread_cache=1
  set-variable    = thread_concurrency=1

-- 
Dan Eischen