List:General Discussion« Previous MessageNext Message »
From:Maximo Migliari Date:January 31 2003 12:01pm
Subject:Re: Configure prob with FreeBSD/Linuxthreads
View as plain text  
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

Thread
Configure prob with FreeBSD/LinuxthreadsJesse Sheidlower28 Jan
  • Re: Configure prob with FreeBSD/LinuxthreadsJeremy Zawodny28 Jan
    • Re: Configure prob with FreeBSD/LinuxthreadsJesse Sheidlower28 Jan
      • Re: Configure prob with FreeBSD/LinuxthreadsJonathan Disher29 Jan
      • Re: Configure prob with FreeBSD/LinuxthreadsJeremy Zawodny29 Jan
  • Re: Configure prob with FreeBSD/LinuxthreadsDan Nelson28 Jan
  • Re: Configure prob with FreeBSD/LinuxthreadsJonathan Disher29 Jan
    • Re: Configure prob with FreeBSD/LinuxthreadsDan Nelson29 Jan
    • Re: Configure prob with FreeBSD/LinuxthreadsGianluca Sordiglioni29 Jan
      • Re: Configure prob with FreeBSD/LinuxthreadsJonathan Disher30 Jan
        • Re: Configure prob with FreeBSD/LinuxthreadsGianluca Sordiglioni30 Jan
          • Re: Configure prob with FreeBSD/LinuxthreadsJonathan Disher30 Jan
            • Re: Configure prob with FreeBSD/LinuxthreadsMaximo Migliari31 Jan
              • Re: Configure prob with FreeBSD/LinuxthreadsDan Nelson31 Jan
                • Re: Configure prob with FreeBSD/LinuxthreadsMaximo Migliari31 Jan
Re: Configure prob with FreeBSD/LinuxthreadsMaximo Migliari31 Jan
  • Re: Configure prob with FreeBSD/LinuxthreadsDan Nelson31 Jan
Re: Configure prob with FreeBSD/LinuxthreadsEric Frazier2 Feb