List:General Discussion« Previous MessageNext Message »
From:Gianluca Sordiglioni Date:January 30 2003 6:00pm
Subject:Re: Configure prob with FreeBSD/Linuxthreads
View as plain text  
> > gcc -v
> Using built-in specs.
> Configured with: FreeBSD/i386 system compiler
> Thread model: posix
> gcc version 3.2.1 [FreeBSD] 20021119 (release)

Okay.

> 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.

>
> 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
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.

> 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.


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