Date: Sat, 22 Feb 2003 17:56:41 +0100 (CET) From: Martin Blapp <mb@imp.ch> To: Simon <simon@optinet.com> Cc: "freebsd-bugs@FreeBSD.org" <freebsd-bugs@FreeBSD.org>, HiTech Creations Support <htsupp@hitechcreations.com> Subject: Re: kern/39878: mysqld process suddenly runs at 99% CPU without load, and a restart of mysqld is required. Message-ID: <20030222175014.P59307@levais.imp.ch> In-Reply-To: <200302221536.h1MFauXM030770@mail.imp.ch> References: <200302221536.h1MFauXM030770@mail.imp.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
> @${ECHO} " WITH_LINUXTHREADS=yes Use the linuxthreads pthread library."
> @${ECHO} " This is _NOT_ recommended for production"
> @${ECHO} " servers. Expect problems when enabled."
I know that. It was true until now.
>
> what is the patch below for?
Mysql did not kill it's threads when using WITH_LINUXTHREADS=yes. So
you were running out of processes and fd's after some time.
Quoting Rick Reed from Yahoo!
> The socket on which MySQL listens for new connections on a blocking
> socket most of the time but is set to non-blocking during the
> accept() of the new connection. Due to a bug in the kernel, the new
> socket returned by accept() is a blocking socket but returns the
> O_NONBLOCK flag when queried via fcntl(F_GETFL). That is, the file
> descriptor and the underlying socket don't agree on the blocking
> mode.
>
> Since MySQL determines via fcntl(F_GETFL) that the socket is
> non-blocking, it expects the first read() in my_real_read to not
> block, so it doesn't enable the timeout alarm. However, the read
> does block, and thus there's no timeout alarm. The thread kill
> (which relies on rescheduling the timeout alarm) also does not work
> as a consequence.
Martin
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030222175014.P59307>