--FO0yZLwVDWUwTKck
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thursday,  2 February 2006 at 10:12:04 +0100, Martin S. Weber wrote:
> On Thu, Feb 02, 2006 at 11:04:12AM +1030, Greg 'groggy' Lehey wrote:
>> (...)
>> For those of you who don't know, one of my other hats is being a
>> developer for MySQL.  Unlike FreeBSD, NetBSD is not a "fully
>> supported" platform for MySQL.  If anybody wants to change that, I'll
>> do what I can to help. (...)
>
> I'm curious.
>
> NetBSD is not "fully supported" means ? ("blame NetBSD not MySQL" ?)

Not really.  It's an issue with the number of resources we can allocate
to support.

> (from the mysql docs[1]: )
>
> [snip]

>       The capability of the kernel and the thread library to take advantage
>       of symmetric multi-processor (SMP) systems. In other words, when a
>       process creates a thread, it should be possible for that thread to run
>       on a different CPU than the original process.
>
> Bad news. Outright broken.

This applies to FreeBSD too AFAIK.  But it's fully supported.  Don't
let it worry you too much.

>       The capability of the kernel and the thread library to run many threads
>       that acquire and release a mutex over a short critical region frequently
>       without excessive context switches. If the implementation of
>       pthread_mutex_lock() is too anxious to yield CPU time, this hurts MySQL
>       tremendously. If this issue is not taken care of, adding extra CPUs
>       actually makes MySQL slower.
>
> ?

Not sure I understand the question.

>       General filesystem stability and performance.
>
> ?

That shouldn't be an issue.

>       If your tables are large, performance is affected by the ability of
>       the filesystem to deal with large files at all and to deal with them
>       efficiently.
>
> How large? :> (ref. der Mouse)

I don't think ufs has any problems in this area.

>       Our level of expertise here at MySQL AB with the platform. If we know
>       a platform well, we enable platform-specific optimizations and fixes
>       at compile time. We can also provide advice on configuring your system
>       optimally for MySQL.
>
> Anyone else but you from nbsd community developing over there ?

No.  And that's the real problem.

>       The amount of testing we have done internally for similar
>       configurations.
>
> I.e. "money"?

MySQL is still an open source company.  The real thing we're trying to
understand is how best to interface with open source operating system
communities (read: "BSD").  Currently we do our own builds of FreeBSD
binaries, and they're not the same as the ones built in the FreeBSD
Ports Tree.  We need to fix that in a way that will allow NetBSD and
others to also be built and tested automatically.

> To change this status, what (aside of fixing threads/SMP) has to be
> done ?  Money poured down the drain ? Or something sensible ?

A couple of good volunteers (pkgsrc maintainers) would probably be
enough, once we convince the Powers That Be to do it this way.  I'm
currently doing some investigation, and will get back to those people
who reply to this message expressing interest.

Greg
--
See complete headers for address and phone numbers.

--FO0yZLwVDWUwTKck
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (FreeBSD)

iD8DBQFD4p8UIubykFB6QiMRAi92AJ427+H0+nz3/ksHDbqf8zHVdeSyEQCfRcbK
jofQsoH6Gb4AQxtsPfpfe5g=
=CTdl
-----END PGP SIGNATURE-----

--FO0yZLwVDWUwTKck--