> > gcc -v
> Using built-in specs.
> Configured with: FreeBSD/i386 system compiler
> Thread model: posix
> gcc version 3.2.1 [FreeBSD] 20021119 (release)
> Because with native threads, enabling the second CPU (and thus locking
> MySQL to one thread, one process, -period-, because running another on
> another port isnt viable) makes the job take just over twice as long.
This explains your point of view: I never tried to run MySQL on
> that's -unacceptable-. Even if I could justify it with "Well, the second
> CPU is handling lots of other stuff", I still can't ignore that MySQL is
> still taking twice as long to do things. And I know, it's a FreeBSD
> problem. I'm waiting for the work done in 5.0 to be evaluated and see if
> it really does make MySQL work better with native threads.
Absolutely. Most of FreeBSD's 4.x kernel functions are not reentrant: to
solve the problem of data corruption if two or more cpu's access the same
procedure, a global locking mechanism is implemented. What it means, in
practice, is that if two processes calls the same kernel function, one has
to wait. They are served sequentially.
The mechanism worked surprising well for most applications, but not for
In MySQL, if I recall right, there's one process that forks many threads,
one for every request. Threads are splitted to many cpus, but because they
compete to access the same functions, some threads have to wait. This could
explain why you experience halved performance.
In FreeBSD 5.x all kernel functions are fully reentrant. They did a great
job in many areas of the OS, often a complete rewrite to gain more
performance and features.
I've not tested FreeBSD 5.0 and MySQL yet, nor I plan to do it soon, because
I'm happy with FreeBSD 4.x in my work. If you do, please let me (us) know.
> If not, this project can't wait. I'll probably have to coerce the boss
> into building a separate db server from the others (which wouldn't be so
> bad) on Linux or Solaris.
Multi-cpu support in Solaris is stable, is efficient, has many years of
development and it's ready to use. There's probably a reason why MySQL AB
develops MySQL on Solaris first.