Hi Laurynas, On Wed, 19 Jun 2013 15:28:29 -0000, Laurynas Biveinis wrote: > Alexey - > > The upstream bug is that the default values have been silently changed from 5.6.11 to 5.6.12 for systems with specific configurations. My patch restores the 5.6.11 behavior that matches all the current docs and cannot have any worse implications than Oracle 5.6.11 itself, which seems quite safe to me. I strongly suspect that the 5.6.12 change was unintended consequence of a refactoring (the commit fixes P_S sizing, does not say a word about changed defaults) and will be either documented as a feature for 5.6.12 post-factum now that they are aware of it, either will be reverted. > So, took me a while to figure all the details, will probably take even longer to explain :) OK, pre-5.6.12 behavior (in 5.6.8 - 5.6.11 to be specific): 1. Read variables values from configuration or use their default values 2. Use them to calculate performance autosized settings 3. Try to set the desired open_files limit based on open_files_limit (or 5000 if it's zero), max_connections and table_open_cache 4. See if were only allowed to raise the limit to a lower value. 5. If that's the case, adjust max_connections and table_open_cache, but only if open_files_limit was 0. I don't think it is (was) documented anywhere, including the open_files_limit=0 prerequisite. There's also an old feature request to change that: http://bugs.mysql.com/bug.php?id=43427 And the purpose of that prerequisite is also unclear. Perhaps to avoid autosizing when a hard-coded "default" value of 5000 is used. 6. Adjust table_definition_cache only if it was not specified explicitly by the user based on the current (possibly adjusted) value of table_open_cache Important things to note here are that: - autosizing of table_open_cache might occur only if open_files_limit=0 and we could not raise the limit to the desired value (not documented) - autosizing of table_definition_cache might occur if it was not specified explicitly (documented, see below) As the 4948 revision comment says, the problem was that Performance Schema autosizing was based on wrong values, i.e. before they are adjusted later. Now enter 5.6.12. What's changed in the above is basically that: - adjustments are performed before perf. schema initialization - the open_files_limit=0 prerequisite for adjusting table_open_cache got dropped. I can see why it was done, it makes the logic unnecessary complicated and again, it was not documented anywhere. Back to http://bugs.mysql.com/bug.php?id=69419: Was it an undocumented change of default values for table_open_cache and table_definition_cache? I don't think so. Docs say that the value of table_definition_cache is autosized by default based on the "400 + (table_open_cache / 2)" formula. No questions here, it was like that before 5.6.12 and is like that in 5.6.12. For table_open_cache, docs say the default value is 2000. This is only half true. It is 2000, if we could reserve the desired number of open files on startup, *and* before 5.6.12 if open_files_limit is 0. Otherwise it is autosized based on the actual open_files limit we could achieve and max_connections. And max_connections could also be autosized, which is another documentation issue. Now even if there's no undocumented defaults changes, we still have a problem with the test suite, which previously relied on the fact that autosizing with open_files_limit!=0 would not occur. A proper fix is probably to fix the test suite to tolerate that autosizing. Which rules out Jenkins slave tweaks, but the other two options I mentioned look acceptable? The proposed fix for http://bugs.mysql.com/bug.php?id=69419 restores the undocumented behavior in 5.6.11 and requires an explanation in Percona Server docs (but does not affect perf. schema autosizing as I wrote before). We also don't know what Oracle will do with that bug. They can fix the test suite and possibly document the current behavior properly, OR restore the previous behavior and possibly document it too, i.e. whatever we do, they can take a different approach. Again, fixing the test suite looks like the least invasive approach for us, because we will always match their behavior and thus not require any explanations in our docs. > If you still want me to change this to match 5.6.12 instead of 5.6.11 then all three options should work, I'd implement the "below threshold" and "above threshold" option. > With the above in mind, yes, please implement that option.