From owner-freebsd-current@FreeBSD.ORG Tue Feb 3 15:06:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E25F616A4CE for ; Tue, 3 Feb 2004 15:06:13 -0800 (PST) Received: from mail.asn.net (mail.asn.net [66.235.231.4]) by mx1.FreeBSD.org (Postfix) with SMTP id E0CB543D53 for ; Tue, 3 Feb 2004 15:06:12 -0800 (PST) (envelope-from kris-fbsdcur@asn.net) Received: (qmail 68258 invoked by uid 80); 3 Feb 2004 23:06:12 -0000 Received: from 68.3.131.72 (SquirrelMail authenticated user kgale) by mail.asn.net with HTTP; Tue, 3 Feb 2004 16:06:12 -0700 (MST) Message-ID: <54758.68.3.131.72.1075849572.squirrel@mail.asn.net> In-Reply-To: <1075842770.23952.15.camel@lanshark.dmv.com> References: <54647.68.3.131.72.1075836867.squirrel@mail.asn.net> <1075842770.23952.15.camel@lanshark.dmv.com> Date: Tue, 3 Feb 2004 16:06:12 -0700 (MST) From: "Kris Gale" To: freebsd-current@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: MySQL with KSE -- Unstable? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2004 23:06:14 -0000 > Ran into a similar situation when I used libmap.conf to use libkse for > apache and mpm worker model. Following the manpage example, I set > default threads to use libthr instead of libc_r. Running a fairly hi > load web/mysql server, I ended up with with the error "unable to create > new threads" and and had to kill the mysql server. It seems that mysql > is partial to libc_r rather than libkse or libthr(?) as changing the > libmap entry back to libc_r for default cured the mysql woes. To get around what you're describing, you should tweak kern.threads.max_threads_per_proc and kern.threads.max_groups_per_proc The default on 5.2 is quite low. Still, I have a feeling once you get this limit increased, you might see a problem similar to the one I described. Kris