maria-developers team mailing list archive

[Arjen Lentz <arjen@xxxxxxxxxxxxx>]

Hi Vlad

On 06/04/2011, at 10:51 PM, Vladislav Vaintroub wrote:
> > From: Philip Stoev [mailto:pstoev@xxxxxxxxxxxx]
> > Right now we have 3 separate things:
> > - server defaults in the code, I belive mysqld.cc
> > - various example .cnf files that are no longer current
> > - windows-specific settings
> >
> > It would be nice if we can get those down to 1 or 2. For example,  
> > have the
> > windows installer use one of the example .cnf files (once those are
> updated
> > to be current to existing hardware).
>
> There is a problem with .cnfs,  they do not scale  with RAM. Also,  
> Arjen
> wants to get the number of example .cnf down to 1, with hardcoded  
> values and
> also make it Unix (with O_DIRECTS , paths with /usr and what else).

Yes i want the number of example cnf files down to 1, and I've  
provided extensive reasoning for it which is also backed up by  
Philip's comments.

However, to state that "Arjen wants ... hardcoded values and also make  
it Unix ..." is a misrepresentation of my position, not backed by any  
email here. I'm fine with removing most or even all such lines where  
possible, as long as it produces a functional result.

O_DIRECT can probably be commented out "by default", removing that  
particular Unix-ism.


> Maintaining a copy "master" my-example.cnf  for Windows, and  
> selectively
> applying  changes to my-example.ini, is not something I'm very keen on
> doing.

If we mark Unix and Windows specifics in a standard way, the build  
system can take care of the rest and we can keep the single config.
It may not be possible to completely eliminate platform dependent  
settings.
This could for instance be done with a special tag in a comment line  
above the relevant option line, or even with a comment/tag on the line  
itself - that can then be cut off during processing both on Unix and  
on Windows.
I don't see it as an "exception for Windows" situation, but rather a  
"fork in the road, we need one of two things here".


> Currently,  I'm trying to  avoid a situation, where people install  
> Oracle's
> MySQL with all defaults, try it out, then install MariaDB with all  
> defaults,
> try it out,  and find out that ours sucks in comparison performance- 
> wise


I don't think making settings RAM-dependent really fixes this.
Benchmarks will always be done badly and sometimes by uninformed  
people, no amount of preemptive handholding will prevent that.

I called my config a baseline, not a default. It provides a sane  
starting point for further tuning necessary for production environments.
So, many other commonly necesasry options will be present but  
commented out, with minimal yet relevant detail.

You can't create a production/benchmark optimal config through  
formulas based on RAM and perhaps a few questions, so please let's not  
waste time on that. It is of course possible to create a config that  
will be optimal for some benchmarks, so if someone were wanting to  
deliver some misdirection out of the box, I'm sure their marketing  
department will make that happen at some point - I'm actually  
surprised it hasn't happened yet ;-)

The one thing we should aim for is to have InnoDB enabled as the  
default engine, because being "ACID out of the box" is vital - it's  
been like that on Windows for years, and Oracle/MySQL has also moved  
to that for Unix from 5.5. This was a longer overdue change of  
default, and the only reason it wasn't done before was the old "MySQL  
AB does not own InnoDB" political situation (but for some reason it  
was ok on Windows, anyway ;-)

Regards,
Arjen.
--
Arjen Lentz, Exec.Director @ Open Query (http://openquery.com)
Remote expertise & maintenance for MySQL/MariaDB server environments.

Follow us at http://openquery.com/blog/ & http://twitter.com/openquery