From owner-freebsd-threads@FreeBSD.ORG Wed Feb 18 08:50:41 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 E391E16A4CE for ; Wed, 18 Feb 2004 08:50:41 -0800 (PST) Received: from mail.asn.net (mail.asn.net [66.235.231.4]) by mx1.FreeBSD.org (Postfix) with SMTP id CAAAC43D2F for ; Wed, 18 Feb 2004 08:50:41 -0800 (PST) (envelope-from kris-fbsd@asn.net) Received: (qmail 97588 invoked by uid 80); 18 Feb 2004 16:50:41 -0000 Received: from 68.3.131.72 (SquirrelMail authenticated user kgale) by mail.asn.net with HTTP; Wed, 18 Feb 2004 09:50:41 -0700 (MST) Message-ID: <50189.68.3.131.72.1077123041.squirrel@mail.asn.net> In-Reply-To: References: <49313.68.106.19.246.1077066168.squirrel@mail.asn.net> Date: Wed, 18 Feb 2004 09:50:41 -0700 (MST) From: "Kris Gale" To: freebsd-threads@freebsd.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal 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: Wed, 18 Feb 2004 16:50:42 -0000 > 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