So, my dear friends, could we conclude that Linux is a more appropriate
platform for running MySQL
on a multi-processed machine?
I was desperate to try and compile MySQL 4.0.9-gamma on my FreeBSD
4.7-stable machine, which is
dual processed. I managed to compile fine once, but it gave errors when
executing the deamon.
I found some instructions for compiling MySQL with linuxthreads on FreeBSD
4.x from one
Jeremy Zawodny, at the website:
http://jeremy.zawodny.com/blog/archives/000458.html
However, my machine complains right at the begining of the configure run that:
.......
checking for gcc... cc
checking for C compiler default output... configure: error: C compiler
cannot create exec
tables
Which is very weird IMHO. I used the configure command found on the page I
pasted above.
Any ideas anyone?
BTW, to any of you who know compiling inside out on *nix machines, what do
the following mean:
-O
-pipe
-march=pentiumpro
-D__USE_UNIX98
-D_REENTRANT
-llthread
-llgcc_r
-felide-constructors
-fno-rtti
-fno-exceptions
Many thanks,
from a n00b FreeBSD admin.
Maximo Migliari.
At 03:21 PM 30-01-03 -0500, you wrote:
> > > 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
> > dual-processor machines.
>
>*nod*. On a single CPU, native threads gives pretty excellent
>performance, in both 4.7-R and 5.0-R. I haven't run a single CPU
>linuxthreads test yet (I think I'll go fire one off...)
>
> > 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
> > MySQL.
> > 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.
>
>I have to say, this is the best explanation of why things work the way
>they do I've seen yet. Thank you.
>
>As far as 5.0, the box I'm testing on is running 5.0-R. Compiling with
>native threads gives near-identical performance to 4.7-R with native
>threads (however, there is a small performance increase in a couple steps
>of the job, which is nice to see. Since the hardware configuration did
>not change, I chalk this up to 5.0-R's rewrite affecting other parts of
>the equation). My assumption right now (and this is based on not having
>taken the time to peruse the code, so I'm likely wrong - ignore me if I
>am) is that MySQL says, "OK, we're running on FreeBSD. Do we have more
>than one CPU present? Yes? OK, lock to one thread." If this is true, we
>are willing to "disable" this protective code (if feasible) and see what
>kind of performance/stability we get out of MySQL on 5.0-R with native
>threads running full bore, unrestricted.
>
>Again, this is just the ramblings of a madman (er, ok, the ramblings of a
>tired sysadmin :).
>
> > > 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.
>
>I wasn't aware that they developed on Solaris first, but I've had
>first-hand experience of Solaris multi-cpu support. It's -great-. I
>almost got a chance to replace an Oracle cluster with MySQL (because the
>support contracts are much cheaper :) in a previous life, but that life
>got the axe too soon.
>
>Again, thanks for that explanation.
>
>-j
>
>
>---------------------------------------------------------------------
>Before posting, please check:
> http://www.mysql.com/manual.php (the manual)
> http://lists.mysql.com/ (the list archive)
>
>To request this thread, e-mail <mysql-thread131256@stripped>
>To unsubscribe, e-mail <mysql-unsubscribe-maximo=migliari.com@stripped>
>Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
