Date: Thu, 23 Dec 1999 15:54:56 -0800 From: "Scott Hess" <scott@avantgo.com> To: <freebsd-hackers@freebsd.org> Subject: Status of kernel threads. Message-ID: <0e7b01bf4da1$1d84d060$1e80000a@avantgo.com>
next in thread | raw e-mail | index | archive | help
I've been looking at hardware upgrades for a production MYSQL server.
While banging on a hardware RAID solution, I found that the performance
improvement for test harnesses hitting MYSQL sucked badly compared to other
tests. My hunch is that the blocking nature of disk I/O is interacting
with FreeBSD's userland pthreads to effectively serialize disk requests
(since disk I/O always blocks, there will never be multiple reads from disk
in progress at a time, so no elevator sorting). To verify the hunch, I ran
multiple MYSQL daemons against the same database (using filesystem locking
to synchronize), and hit each of them with 1/N of the load from the earlier
test. Indeed, the N-daemon version ran much faster overall, and showed
much greater iostat numbers.
Does my evaluation of the problem make sense? [For reference, in the
2-mysqld case, I ran 2 mysqld processes against a single set of tables on
different ports, and hit each port with 2 100-unit client loads apiece, and
1-unit loads finished about 25% faster, while iostat tps numbers were about
40% higher. With 4 mysqld processes and 1 100-unit client load apiece,
units finished an additional 10% faster and iostat tps went up another 30%.
All against a 32M cache SCSI-SCSI RAID5 controller with 6 10krpm drives.]
I periodically hear reference to kernel threads - but from what I can tell
from following these lists for a couple months, and also searching the
archives, kernel threads aren't quite "there" yet ("there"=="can
use -kthread instead of -pthread and away we go"). Am I just missing the
right search phrases?
Assuming the "kernel threads" still means "LinuxThreads" and not something
new that I haven't found, does anyone have any positive or negative
comments on how reasonable LinuxThreads on FreeBSD is for production use?
Is it stable, or still in development?
Thanks,
scott
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?0e7b01bf4da1$1d84d060$1e80000a>