Date: Tue, 02 Mar 2004 12:07:15 +0100 From: Uwe Doering <gemini@geminix.org> To: questions@freebsd.org Subject: Re: MySQL and FreeBSD 4.x.. problems, problems with server Message-ID: <40446AE3.7000308@geminix.org> In-Reply-To: <055201c3fe85$b3cda490$6401a8c0@yourqqh4336axf> References: <055201c3fe85$b3cda490$6401a8c0@yourqqh4336axf>
next in thread | previous in thread | raw e-mail | index | archive | help
dap wrote: > This has happened with enough servers at different locations that I have to > believe there is a relationship here. I have servers running the latest > release of MySQL. I've run the servers on FreeBSD 4.4., 4.7, and 4.8. I am > not using the threaded version. MySQL always uses threads. It's just that you have the choice which implementation to use, native or Linux threads. > On all three versions, on different servers > at different sites, I have seen MySQL just go wacky after a while. > > Two types of symptoms: > > 1. mysqld just decides to consume as much of the CPU as possible. > 2. new connections to mysql fail > > It will usually take 1-3 weeks between occurances. > [...] > Yes, this is a mysql problem probably, and not a FreeBSD problem. However, > I'm hoping to get some help or hope here as well as with the mysql people. > :) There have been some fixes lately to 'libc_r', the threads lib MySQL uses by default on FreeBSD 4.x. They deal with EOF conditions in connection with write(2) which may very well cause process looping. This programming error could be the cause of your problem as well, so it might be worthwhile to take a look at the latest CVS commits to 'uthread_write.c': http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc_r/uthread/uthread_write.c?sortby=date&only_with_tag=RELENG_4 BTW, a potentially serious problem with signals in 'uthread_join.c' has been fixed recently, too. Hope it helps in your case. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40446AE3.7000308>