Date: Wed, 18 Feb 2004 23:22:51 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Kris Gale <kris-fbsd@asn.net> Cc: freebsd-threads@freebsd.org Subject: Re: More on MySQL -- Fatal trap 12 Message-ID: <Pine.GSO.4.10.10402182316210.12150-100000@pcnet5.pcnet.com> In-Reply-To: <50189.68.3.131.72.1077123041.squirrel@mail.asn.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10402182316210.12150-100000>