Date: Sun, 21 Feb 1999 23:30:11 -0800 (PST) From: Dru Nelson <dnelson@redwoodsoft.com> To: freebsd-hackers@freebsd.org Subject: RE: SMP and libc_r (mysql) Message-ID: <Pine.BSF.3.91.990221225559.3568N-100000@pacman.redwoodsoft.com>
next in thread | raw e-mail | index | archive | help
User space threads (like the one used by MySQL) are actually great as far as threads packages go. However, it can onlny block nicely on sockets, pipes, char devices, etc. It really doesn't schedule well around blocking file reads and writes. I believe it uses a signal to cause the scheduler to kick in (a signal is not an inexepensive thing) and switch threads... So, with MySQL, which does A LOT of file seeks/reads/writes etc, it might be better to have some kernel support (Which IS comming RSN) to schedule around that I/O blocking. However, its existing performance may be fine for the problem you are trying to solve (it is very fast). Am I too far off on this one guys.... Three side notes: 1. We use MySQL, and we found the performance to be a little better under linux (however, we have the 2 GIG limit on the linux system, and we're not going to patch around this just yet). However, when memory gets scarce it dies horribly. 2. MySQL is not that great. I know this is heresy, but it's true. When you have a lot of clients banging on the server, a database that can do row level locking is a lot nicer. (Also, the database's lack of real transactions and real replication bothers me a lot.) So, you might want to look around. Otherwise, it is great for getting a project done quickly. 3. You might look into getting a really fast RAID and a lot of memory. This will do wonders for your database... Dru Nelson Redwood City, California 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?Pine.BSF.3.91.990221225559.3568N-100000>