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>