From owner-freebsd-threads@FreeBSD.ORG Wed Feb 18 20:22:56 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A58BF16A4CE for ; Wed, 18 Feb 2004 20:22:56 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CEC643D1D for ; Wed, 18 Feb 2004 20:22:56 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i1J4MpSQ014126; Wed, 18 Feb 2004 23:22:52 -0500 (EST) Date: Wed, 18 Feb 2004 23:22:51 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Kris Gale In-Reply-To: <50189.68.3.131.72.1077123041.squirrel@mail.asn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: More on MySQL -- Fatal trap 12 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2004 04:22:56 -0000 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