Date: Tue, 10 Feb 2004 16:08:58 -0700 (MST) From: "Kris Gale" <kris-fbsd@asn.net> To: "David Xu" <davidxu@viatech.com.cn> Cc: freebsd-threads@freebsd.org Subject: Re: Question about threads [beaver challenge] Message-ID: <53632.68.3.131.72.1076454538.squirrel@mail.asn.net> In-Reply-To: <4029627F.4090602@viatech.com.cn> References: <1076398781.b793f9a0dkt@digitalme.com> <51993.68.3.131.72.1076432061.squirrel@mail.asn.net> <20040210193240.GA47392@crodrigues.org> <53224.68.3.131.72.1076449765.squirrel@mail.asn.net> <4029627F.4090602@viatech.com.cn>
next in thread | previous in thread | raw e-mail | index | archive | help
> What's the value of your sysctl kern.threads.max_threads_per_proc and > kern.threads.max_groups_per_proc ? Mysql heavily uses system scope > thread. I set them both to 2500. Just to reiterate my problem... I wasn't having any problems with MySQL starting up new threads. The problem was that MySQL would slow to a crawl, and then become completely unresponsive. I capture the number of threads periodically so I can graph it, and what I would see when MySQL started to slow was that the number of threads would be about twice what it should have been, given the load on the web application. It appeared that threads were being created, but would hang around forever, or that all of the queries were backing up. Attempting to stop and start the MySQL daemon while the client application (comprised of several hundred httpd processes) was trying to reconnect would end up crashing the entire OS, causing the machine to reboot. This never happened when I was near the console, and none of the logs contained any crash messages. Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53632.68.3.131.72.1076454538.squirrel>