Date: Mon, 10 Jan 2000 15:36:23 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Scott Hess" <scott@avantgo.com> Cc: <freebsd-hackers@FreeBSD.ORG>, <developer@lists.mysql.com> Subject: Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD. Message-ID: <200001102336.PAA31453@apollo.backplane.com> References: <1a6101bf5bc1$4e364b20$1e80000a@avantgo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:Recently I was tasked to find a way to scale up our MYSQL server, running
:MYSQL3.22.15 on FreeBSD3.3. I've been testing a hardware RAID solution,
:and found that with 6 disks in a RAID5 configuration, the system was only
:perhaps 30% faster than when running on a single disk. [The 6 disks in the
:RAID5 are the same model as the single-disk test I was comparing against.]
:
:Experimentation determined that pthreads was the problem. FreeBSD's
:implementation of pthreads using a select() loop, and select() always says
:that disk I/O is ready to proceed, and disk I/O never return EWOULDBLOCK.
:Essentially, pthreads was serializing the MYSQL read() requests, and if the
:dataset exceeds memory size, performance becomes entirely seek bound.
:
:I've implemented a rough fix, which is to rfork() processes which I label
:...
:Thanks,
:scott
A better solution may be to shift to FreeBSD4.0 (when it's released -
wait for it to become good and stable), and then use the native
linuxthreads port (/usr/ports/devel/linuxthreads) for FreeBSD.
The linuxthreads port is at least four times faster and, since it uses
rfork(), will be I/O optimal. However, since only FreeBSD-4.x implements
rfork(...RF_MEM) you can only use it with FreeBSD-4.x (or am I wrong
there?).
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001102336.PAA31453>