Hi Vlad On 06/04/2011, at 10:51 PM, Vladislav Vaintroub wrote:
From: Philip Stoev [mailto:pstoev@askmonty.org] 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