- developers - lists.mariadb.org

Re: [Maria-developers] [GSoC] Optimize mysql-test-runs - Results of new strategy
by Pablo Estrada 19 Aug '14

19 Aug '14

Hello Elena and all, First, addressing the previous email: Looking at the dump, I see it can also happen that the dump contains > several records for a pair platform/bbnum. I am not sure why it happens, I > think it shouldn't, might be a bug in buildbot and/or configuration, or > environmental problems. Anyway, due to the way we store output files, they > can well override each other in this case, thus for several platform/bbnum > record you will have only one file. I suppose that's what was hard to > resolve, sorry about that. > No worries ; ). There are several cases where platform and build number are the same. The system just names the files as follows: <platform>_<build_id>-log-test_1-stdio <platform>_<build_id>-log-test_2-stdio ..... <platform>_<build_id>-log-test_5-stdio These files seem to correspond temporarily with the test runs (*test_1-stdio) belongs to the first test_run of the same plt-bnum, and so on. Unfortunately, there are some cases where there are more test_runs on the dump than files available, and this means that it's impossible to be sure which file belongs to which test_run exactly. > You should consider skipped tests, at least for now. Your logic that they > are skipped because they can't be run is generally correct; unfortunately, > MTR first produces the *full* list of tests to run, and determines whether > a test can be run or not on a later stage, when it starts running the > tests. Your tool will receive the initial test list, and I'm not sure it's > realistic to re-write MTR so that it takes into account limitations that > cause skipping tests before creating the list. > I see. Okay then, duly noted. Possibly it's better to skip a test run altogether if there is no input > list for it; it would be definitely the best if there were 5K (or whatever > slice you are currently using) of continuous test runs with input lists; if > it so happens that there are lists for some branches but not others, you > can skip the branch entirely. > This doesn't seem like a good option. Recall drops seriously, and the test_runs that have a corresponding file don't seem to have a special pattern, and tend to have long spaces between them, so the information becomes irrelevant, and seemingly, not useful. > The core module should take as parameters > - list of tests to choose from, > - size of the running set (%), > - branch/platform (if we use them in the end), > and produce a new list of tests of the size of the running set. > > The wrapper module should > - read the list of tests from the outside world (for now, from a file), > - receive branch/platform as command-line options, > - have the running set size set as an easily changeable constant or as a > configuration parameter, > > and return the list of tests -- lets say for now, in the form of <test > suite>.<test name>, blank-separated, e.g. > main.select innondb.create-index ... > >> >> I am almost done 'translating' the code into a solution that divides it in 'core' and 'wrapper'. There are a few bugs that I still haven't figured out, but I believe I can iron those out pretty soon. I will also incorporate the percentage rather than fixed running_set. Now, regarding the state of the project (and the recall numbers that I am able to achieve so far), here are some observations: - Unfortunately, I am running out of ideas to try to improve recall. I tried tuning some parameters, giving more weight to ones or others, etc. I still wasn't able to push recall beyond ~87% on the strategy that uses file correlations. For what I've seen, some failures are just extremely hard to predict. - The strategy that uses only a weighted average of the failure frequency achieves a higher recall, but for a shorter time. The recall decays quickly afterwards. I may try to add some file-correlations to this strategy, to see if the recall can be sustained for a longer term. - There is one problem that I see regarding the data and the potential real-world implementation of the program: By verifying the recall with the historical data, we run the possibility of 'expecting' overfitting... so the results regarding the errors found when comparing to the historical data, and the results that could have been obtained by a real-world implementation are potentially different. A possible way to address that issue would require modifying the buildbot to gather more data over a longer term. So having said that, I am looking for some advice in the following regards: - I will try to take a step back from the new strategy, and see how I can adapt the original strategy to prevent the recall function from declining so sharply with time. - I will also spend some time keeping a codebase that adjusts better to the model that we need for the implementation. I will upload code soon. All suggestions are welcome. - Nonetheless, I feel that more data would allow to improve the algorithm greatly. Is it possible to prepare logging into the buildbot that would allow for more precise data collection? A slower, more iterative process, working closer with the buildbot and doing more detailed data collection might deliver better results. (I understand that this would probably influence the time-scope of the project) Let me know what you think about my suggestions. Regards Pablo

2 22

[Maria-developers] [GSoC] Week Twelve!
by sriram patil 14 Aug '14

14 Aug '14

Hi All, Following is the link to my twelfth weeks blog post. http://goo.gl/Zkr86e Suggestions and/or reviews are welcome! Thanks, Sriram

3 2

[Maria-developers] Fwd: I have a replication patch, please accept it.
by Colin Charles 12 Aug '14

12 Aug '14

Xu Liang, the best place to post it is maria-developers I've done that via a FWD -- Kristian, what do you think? Begin forwarded message: > From: "Xu,Liang(OP)" <xuliang02(a)baidu.com> > Subject: I have a replication patch,please accept it. > Date: 6 August 2014 15:31:27 GMT+8 > To: "kb-admins(a)askmonty.org" <kb-admins(a)askmonty.org> > > http://bugs.mysql.com/bug.php?id=73479 > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Baidu DBA 徐良 > 分机：86912826 > 手机：18689220441 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Colin Charles, Chief Evangelist, SkySQL - The MariaDB Company blog: http://bytebot.net/blog/| t: +6-012-204-3201 | Skype: colincharles

1 0

[Maria-developers] MariaDB 10.0.13 Release Prep
by Daniel Bartholomew 11 Aug '14

11 Aug '14

I've begun the prep work for the MariaDB 10.0.13 release. Draft changelog and release notes are here: - https://mariadb.com/kb/en/mariadb-10013-release-notes/ - https://mariadb.com/kb/en/mariadb-10013-changelog/ A big thanks to those that have already contributed content! As always, please let me know ASAP if anything else needs to be added/changed/etc..., or jump in and do it yourself. Thanks! -- Daniel Bartholomew, MariaDB Release Manager MariaDB | http://mariadb.com

1 0

[Maria-developers] innodb-buffer-pool-instances confusion
by Daniel Bartholomew 07 Aug '14

07 Aug '14

I was chatting with some folks on IRC and someone pointed this out to me. On the "Upgrading From MariaDB 5.5 to MariaDB 10.0" page, it says that the new default value for innodb-buffer-pool-instances is '0': https://mariadb.com/kb/en/upgrading-from-mariadb-55-to-mariadb-100/ And when I run the following, it says the default is indeed '0': mysqld --no-defaults --verbose --help | grep innodb-buffer-pool-instances ... innodb-buffer-pool-instances 0 But when I'm in the client, I get the following: MariaDB [(none)]> select @@innodb_buffer_pool_instances; +--------------------------------+ | @@innodb_buffer_pool_instances | +--------------------------------+ | 8 | +--------------------------------+ So when innodb-buffer-pool-instances is set to '0', does that mean the actual value is dynamic or calculated in some way based on my other settings? Just trying to understand what's going on, and once I do, use it to update the XtraDB/InnoDB buffer-pool page (which doesn't appear to have been updated for 10.0). https://mariadb.com/kb/en/xtradbinnodb-buffer-pool/ Thanks! -- Daniel Bartholomew, MariaDB Release Manager MariaDB | http://mariadb.com

4 3

[Maria-developers] CONNECT system variables
by Ian Gilfillan 07 Aug '14

07 Aug '14

Hi I am trying to document the CONNECT system variables at https://mariadb.com/kb/en/mariadb/documentation/storage-engines/connect/con… but I can't seem to find much documentation in the code. I managed to put something together from Olivier's notes in JIRA for some of them, but can anyone help fill in the gaps and send me details on the other variables? thanks, ian

1 0

[Maria-developers] a question about group commit
by nanyi607rao 07 Aug '14

07 Aug '14

Hi, as we know there are 3 steps in XA transaction committing 1, prepare step 2, write binary log 3, commit step in engines all these steps need a fsync(). Group commit strategy can make a group of transactions durable with one fsync() at step 2 and step 3, which can lead to dramatic performance enchance. But in step 1, each transaction still do its own fsync(). so why not make several transactions durable whith one fsync() in prepare step just like step 2 and 3, which I think can improve performanc further more ? Thanks 2014-08-04 nanyi607rao

2 3

[Maria-developers] [GSoC] Week Eleven!
by sriram patil 05 Aug '14

05 Aug '14

Hi All, Following is the link to the blog post for my eleventh week into GSoC http://goo.gl/TN3U0K Suggestions and/or reviews are welcome. Thanks, Sriram

3 2

[Maria-developers] MariaDB 5.5.39 Release Prep
by Daniel Bartholomew 05 Aug '14

05 Aug '14

All, I've begun prep work on the MariaDB 5.5.39 release. Draft release notes and changelog are here: - https://mariadb.com/kb/en/mariadb-5539-changelog/ - https://mariadb.com/kb/en/mariadb-5539-release-notes/ Please add any necessary or notable items to the release notes ASAP. Current plan is to activate/announce the release on 5 Aug. Thanks! -- Daniel Bartholomew, MariaDB Release Manager MariaDB | http://mariadb.com

1 0

[Maria-developers] Connector Coding till 5th Aug
by Puneet Dewan 05 Aug '14

05 Aug '14

Hi Everyone, Last week, 1.I was working on the Binary Protcol Resultset which is still going on. 2.Added code for Batch Statements in MySQlServerSidePreparedStatement. 3.Added utility methods in ParameterWriter.java for sending different parameters in Binary Protocol format. 4.Code review with Massimo This week, 1.Complete the Binary protocol resultset. 2.Test cases for batch statements and allowmultiqueries. 3.Code review with Massimo. Regards Puneet.

1 0