# Copyright (C) 2019 MariaDB corporation Ab. All rights reserved. Use # is subject to license terms. # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; version 2 of the License. # # This program is distributed in the hope that it will be useful, but # WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 # USA use GenTest::Grammar; # Configuration file template for using rqg_batch.pl for simplifying RQG tests # # Please # - Copy this file to for example 1.cfg and # - Adjust the settings so that they fit to your use case and environment. # # # Anything which is relevant for the simplification process itself # == lib/Simplify.pm needs to know that # must or should be on top level and not nested into 'rqg_options'. # { # desired_status_codes #--------------------- # Lists of # desired results --> whitelist_* # unwanted results --> blacklist_* # RQG exit statuses --> *_statuses # text patterns in RQG log --> *_patterns # which allow RQG tools to make a verdict if some RQG run replayed # the result defined by that or not. # What counts here is getting # Auxiliary::RQG_VERDICT_REPLAY ('replay') # which means we had a whitelist match (in minimum one element per list) # and no blacklist match (no element of the two lists). # # Regarding statuses: # The complete list of statuses is in lib/GenTest/Constants.pm. # Just the most important ones: # STATUS_SERVER_DEADLOCKED STATUS_REPLICATION_FAILURE # STATUS_VALGRIND_FAILURE STATUS_BACKUP_FAILURE # STATUS_RECOVERY_FAILURE STATUS_ENVIRONMENT_FAILURE # STATUS_ALARM(RQG core sees problem but has no idea why) # STATUS_SERVER_CRASHED STATUS_DATABASE_CORRUPTION # STATUS_ANY_ERROR(any status != STATUS_OK) # We do no more take the exit status of the process running RQG because of technical reasons. # The status is taken from a line containing # 'RESULT: The RQG run ended with status ' # and written direct after finishing GenTest into the log of the RQG run. # # Regarding text patterns: # The search patterns are often derived from a backtrace found in the log of some # historic RQG run. # Example: # Starting point is a crash of a server which was compiled with debug. # A text patterns could match a group of lines. # white_list_patterns => # [ # "'assert.{0,150}safe_cond_timedwait.{0,150}thr_mutex\.c.{0,50}Item_func_sleep::val_int.{0,3000}SELECT 1,SLEEP\(10\)'" # ]; # # Please be careful when using # - characters with special meaning in pattern matching like +?.*^$()[]{}|\ # Use '\' in order to disable the special meaning or just replace any suspicious character # by a '.' in case the pattern is already selective enough. # - memory addresses or source code line numbers # They are brilliant selective but might stop to work after the next pull source + compile. # # # "Unsharp" whitelists: # Example1: # # A lot Innodb asserts get matched by this pattern. # 'mysqld:.{1,150}innobase.{1,1000} Assertion .{1,500} failed.', # Example2: # # Bug A # 'InnoDB: Failing assertion: \!cursor->index->is_committed\(\)', # # Bug B # 'mysqld: .{1,150}data0data.h:.{1,20} dfield_t. dtuple_get_nth_field.{1,30}: Assertion .n < tuple->n_fields. failed.', # # Bug C # 'mysqld: .{1,150}lock0lock.cc.{1,20} my_bool lock_rec_other_trx_holds_expl_callback.{1,150}: Assertion .\!expl_lock \|\| expl_lock->trx == arg->impl_trx. failed.', # # Bug D # 'mysqld:.{1,200}btr0cur.cc:.{1,30}dberr_t btr_cur_search_to_nth_level_func.{1,500} failed', # # Basic approach/logics of such a setup: # I do not care for which assert we simplify first as one of the patterns matches. # # Advantage: # The simplifier run will result in (artificial example related to Example2 above): # The simplification starts with grammar table_stress.yy which gets transformed to p0.yy # and delivers a series of grammars p*.yy and final.yy. # Smallest replaying grammar (final.yy) -- Bug C # There are bigger grammars replaying C but they could be ignored. # Smallest grammar replaying Bug A, but bigger than final.yy, is p.yy # It is to be expected that this grammar could also replay Bug C. # Smallest grammar replaying Bug B, but bigger than p.yy, is p.yy # It is to be expected that this grammar could also replay Bug C and A. # ~ Grammar size/complexity: p0.yy > p.yy > p.yy > final.yy # Bug D does not get replayed from reasons like # - grammar is not capable to replay it at all # - Bug D is fixed # # How to go on: # Manual simplification etc. for Bug C based on final.yy or the p.yy with highest . # Move the pattern for Bug C from the white_list_patterns to the blacklist_patterns. # Restart the grammar simplification for Bug A based on p.yy. # Manual simplification etc. for Bug A based on the new final.yy. # ... # The win is that the simplification for BUG A does not start with table_stress.yy # which is serious more complex than p.yy. And that saves a lot elapsed time. # Disadvantage: # No control over for which bug you get full simplification first. # But its quite likely that the best replayable bug will get full simplification first # compared to the other. # # Main purposes of the blacklists during grammar simplification: # 1. When going with some "unsharp" whitelists like (logically) # "I do not care for which assert we simplify first as long its an assert # (and not STATUS_SERVER_DEADLOCKED) ..." # than the simplifier might finally focus on some open bug (assert too) where we already # have a nice replay testcase. So starting at some point of time during the simplification # process we might just waste resources till end of the simplifier run. # Good blacklists and whitelists could avoid that. # 2. At least some RQG tools collect and preserve any RQG test results which are not what we are # focused on but at least of interest. # Example: # We have some "sharp" whitelists focusing on assert Y only but have just hit assert Z. # In case assert Z is some open bug where we already have a nice replay testcase than preserving # the remainings wastes resources like CPU and IO at least temporary and storage space on disk # for a longer timespan. Good blacklists ... # # Important: # The blacklist matching is performed first. So it overrules the whitelist matching. # whitelist_statuses => [ # 'STATUS_ANY_ERROR', 'STATUS_SERVER_CRASHED', ], whitelist_patterns => [ '.{1,200} in fil_system_t::keyrotate_next', # 'InnoDB: Failing assertion: \!space->referenced\(\)', # 'Assertion .\!space->referenced\(\). failed', # '', # 'mysqld:.{1,150}innobase.{1,1000} Assertion .{1,500} failed.', ], blacklist_statuses => [ 'STATUS_OK', ], blacklist_patterns => [ # RQG runs showing this pattern end usually with the status # STATUS_ENVIRONMENT_FAILURE(110). In case its a grammar maintained by hand than the # grammar is faulty and should be corrected. # But grammar simplification and also grammar masking run some automatic mangling of # grammars which could lead to the same effect because of non avoidable and harmless # reason. So we throw the remainings of such runs away and save by that resources. 'Possible endless loop in grammar.', # # Grammars could have the unfortunate runtime property to cause some dramatic growth # of storage space consumption. This is especially valid in case of grammars generated # during simplification. # Example: All DROPs and DELETEs were shrinked away. # Some typical outcome is: # The server asserts, threads and/or periodic reporters exit with (hopefully) # STATUS_SERVER_CRASHED, the reporter Backtrace prints content of the server error log # and lets some debugger analyze the core file and than RQG exits with (again hopefully) # STATUS_SERVER_CRASHED. # Than in case of some "unsharp" setup of the whitelists (statuses == STATUS_ANY_ERROR, # patterns empty) that all gets valuated as replay. # But its either # - (most likely) a replay of some known "natural" effect which is not a defect # or # - (quite unlikely) the replay of a defect but the surviving data are not sufficient # for analysis and we should better not waste time on that. # Conclusion: # Runs where we hit trouble with storage space are "unwanted". # Server error log pattern: ..... (Error 28 is OS: No space left on device) # [ERROR] InnoDB: preallocating 12582912 bytes for file ./test/#sql-1f36d_10.ibd failed with error 28 # [ERROR] InnoDB: preallocating 65536 bytes for file ./test/FTS_0000000000000524_00000000000005f9_INDEX_5.ibd failed with error 28 '\[ERROR\] InnoDB: preallocating .{1,120} with error 28', # Debugger output pattern: # BFD: Warning: is truncated: expected core file size >= 959647744, found: 55398400. ' is truncated: expected core file size ', ], # simplify_chain defines which test simplification steps/phases should be executed and # in which order. simplify_chain => [ #### PHASE_FIRST_REPLAY #### # Attempt to replay with the compactified initial grammar. # Main purpose: # Check if the whitelist/blacklist statuses/patterns fit because otherwise the # simplification run is valueless. No replay within $trial finished attempts leads to # abort of simplification process. # In case you are believing (*) that the list setup is good # - than you can save some (usually a few minutes up till 0.5h (**)) of the total # simplifier runtime by omitting this phase. # - and fear that $trials might be too small for replaying and also hesitate to # increase $trials from whatever reason than omitting this phase gives you # roughly endless trials on different minimal simplified grammars. # Default: 'first_replay' enabled and first phase. 'first_replay', # #### PHASE_THREAD1_REPLAY #### # Attempt to replay with the actual best (usually the compactified initial) grammar # and threads = 1. # Main purpose: # Check if the desired outcome might be a single user effect. # If yes we can # - apply some simplifications depending on grammar content # ==> reduce complexity # ==> (hopefully) speedup of simplification process which maybe follows # or # - also bail out (corresponding functionality is currently missing). # ==> Setup (manually) mysqltest simplification and start that. # mysqltest simplification is usually serious faster but the manual setup costs # frequent serious efforts. # In case you are believing (*) that its a concurrency problem than you can save some # (usually a few minutes up till 0.5h (**)) of the total simplifier runtime by # omitting this phase. # Default: 'thread1_replay' enabled and second phase. # 'thread1_replay', # #### PHASE_RVT_SIMP #### # Attempt to shrink the amount of reporters, validators, transformers. # Main purpose: # Reduce complexity and (hopefully) speedup of simplification process which maybe follows. # In case you are believing (*) that the reporters, validators, transformers used are # either required or do not consume significant runtime than you can save some # (usually a few minutes up till 1h (**)) of the total simplifier runtime by # omitting this phase. # Default: 'rvt_simp' enabled and third phase. # 'rvt_simp', # #### PHASE_GRAMMAR_SIMP #### # Attempt to shrink (remove components of grammar rules, inline rules etc.) the actual best # replaying grammar. It is never tried to replace the last component of a rule by an empty # string. == We do not take the risk to maybe change the semantics of the test. # Main purpose: # Reduce complexity and (hopefully) speedup of simplification process which maybe follows. # Default: 'grammar_simp' enabled and fourth phase. 'grammar_simp', #### PHASE_GRAMMAR_DEST #### (Alternative to PHASE_GRAMMAR_SIMP) # Like 'grammar_simp' but it is also tried to replace the last component of a rule by an # empty string. == We take the risk to maybe change the semantics of the test. # Typical use case: # We simplify for a server crash caused by the server itself. # Example: The server asserts when having to execute certain SQL in some situation. # Compared to PHASE_GRAMMAR_SIMP: # - In case some rule consisting of n > 1 unique components could be shrinked to an # empty string only than we might save up till n - 1 RQG runs. # - We will get up till number of valid rules additional RQG runs per campaign. # - In case the components of a top level rule like query could be replaced by the # empty string than the final replay becomes faster and its becomes more obvious that # the root of the bad outcome is most probably before YY grammar processing. # Examples of contra indications: # - We have queries consisting of several SQLs followed by validation. # PHASE_GRAMMAR_DEST might destruct one or more of these SQLs and than we might get # false positives if the validator is not prepared for that case. # - Threads maintain entries in some table and kill each other. # In case that maintenance is partial harmed than the replay likelihood could # decrease drastic. # - Partially surprising uncomfortable effects during manual grammar simplification later. # Default: 'grammar_dest' not enabled. # 'grammar_dest', # #### PHASE_GRAMMAR_CLONE ### # Attempt to transform the grammar by cloning of more than once used rules. # Example: # Original grammar =========> Transformed grammar # rule1: rule1: # SELECT where | SELECT __clone_1 | # UPDATE where ; UPDATE __clone_2 ; # where: __clone_1: # WHERE col1 = 2 | WHERE col1 = 2 | # WHERE col2 BETWEEN 3 AND 7; WHERE col2 BETWEEN 3 AND 7; # __clone_2: # WHERE col1 = 2 | # WHERE col2 BETWEEN 3 AND 7; # # In case that is leading to some grammar which differs from the current best one than # grammar simplification is tried (Repetition of PHASE_GRAMMAR_SIMP described above.) # # Main purposes ordered by likelihood that they happen: # 1. Faster replay of the problem, faster manual simplification faster bug fixing. # But also longer (up to a few hours) lasting "automatic" simplification. # 2. Have some serious better distribution of statement generation over concurrent # threads/sessions. # Example: # Let's assume in the original grammar # - many threads use "query" as top entry # - "query" generates a broad range of DDL and DML # Depending on the case bug fixers frequent prefer if only a few sessions run # DDL but no DML or only ALTER .... at all and similar. # When enabling the simplification step 'grammar_clone' than its serious more # likely that we finally end up with some more extreme distribution. # This provides also some serious better base for developing some replay test based # on my shellscript "mysqltest_background.sh" and MTR as tool. # == Replay without the rapid changing and rather heavy RQG infrastructure. # 3. The final grammar generates less different SQL. # # Please note that the first parent grammar after cloning does not generate # - different SQL in general # - some different distribution or frequency of SQL # Negative example: thread1 runs now UPDATEs at all or more than previous. # than the previous parent grammar. # But the new parent grammar might have a several times bigger amount of lines. # Default: 'grammar_clone enabled and fifth phase. 'grammar_clone', #### PHASE_FINAL_REPLAY #### # Attempt to replay with the final simplified test. # Main purpose: # Check how fast some replay could be achieved with that setup and YY grammar. # Default: 'final_replay' enabled and sixth phase. 'final_replay' # (*) Its not that likely that mistakes have a dramatic bad impact. # (**) The time range mentioned is nothing else than some qualified guess based on # experiences. The range depends on $trials, $parallel, how likely the effect you # are simplifying for shows up etc. # At runtime its quite often like # - Saving a few hours looks on the first view impressing but the total simplification # runtime was even without that more than 30 hours. So the win is often <= 10%. # - If partially manual working on some already automatic simplified test including # "active" waiting for results omitting no more necessary simplification steps # could be some serious win or makes you at least a bit happy. # ], # grammar_file #------------- # File which should be used as the base for the simplification process. # It should be an "effective" YY grammar == # - grammar + redefine files are already merged/joined # - any masking was already applied # # Recommendation: # Think about setting '--grammar=......' via command line option like # # perl rqg_batch.pl ... --grammar= # # This will override any setting of grammar in the config file # - top level section # - "rqg_options" section # grammar => 'conf/mariadb/innodb_compression_encryption.yy', # redefine files #--------------- # Do not set redefine files here or in the rqg_options section because the RQG test simplifer will # ignore them! # threads => 13, queries => 1000000, # duration and duration_adaption # ------------------------------ # duration assigned to some RQG runner like rqg.pl # == Maximum YY grammar processing time. # duration assigned to rqg_batch.pl # == A value used for computing the duration assigned to some RQG run. # Default: 300 seconds duration => 300, # # duration_adaption == which function to use for adapting the duration assigned to RQG runs # # duration_adaption value for duration assigned to the next RQG run started # 'None' duration (here) == No adaption at all. # Have a fifo containing the real (*) YY grammar processing times of the last 10 replaying RQG # runs. (*) If value measured > duration (here) than only charge duration (here). # 'Maximum' Minimum of (duration (here), maximum(fifo)) # 'MaximumMiddle' (duration (here) + maximum(fifo)) / 2 # 'Experimental' Some value computed based on formula for Gaussian distribution (**). # (**) We have definitely not a Gaussian distribution but the formula # delivers quite usable values. # This is the default. duration_adaption => 'Experimental', # Hints about how to speed up especially the simplification process # 1. Add 'None' to the list of reporters and validators in case you are sure that you do not # need stuff added per default. # 2. In case you simplify for whitelist_patterns matching messages written by the server or # other tools # Example: 'InnoDB: Failing assertion: opt_no_lock' # and not for parts of backtraces than use the reporter 'ServerDead' instead of 'Backtrace'. # The gain in simplification speed will be > 50%. # 3. As long as certain open bugs about server freezes are not fixed and frequent used grammars # will replay them frequent please add the reporter # 'Deadlock1', # even if not searching for these freezes. # RQG tests which have no more a chance to replay what you are searching for will get # earlier detected and terminated. reporters => [ 'ErrorLog', 'Backtrace', # 'RestartConsistency', ], validators => [ 'None', ], transformers => [ # Do not assign here a 'None'. ], # Do NOT assign basedirs etc. here # rqg_options #------------ # rqg.pl (RQG runner) options which should be used # Warning: # You can define threads, validators etc. also within the RQG option block. # But please be aware that any setting != 0, undef or '' being outside like # - outside of the rqg_options block within the config file # - within the rqg_batch.pl call # will be glued to the end of the final RQG call line and hereby "win". # rqg_options => { restart_timeout => 30, # 'noarchiving' will make the complete simplification process significant faster. # Disadvantages: # - You need to rerun the RQG test later with replay of desired outcome in order to get # the corresponding archive containing a core, content of server datadir etc. # This is most probably only a small extra work because simplified tests replay than # usually faster. # - You also need to rerun the test for outcomes with the verdict 'interest' in case # you are really interested in them. # I recommend to set the next line to comment only if # - having a lot of time or assuming that the simplification will last long anyway # (maybe because the desired outcomes showed up quite rare) # and/or # - going with quite "unsharp" whitelist_patterns so that harvesting several different # bad outcomes seems to be likely. noarchiving => undef, engine => 'InnoDB', gendata => 'conf/mariadb/innodb_compression_encryption.zz', # gendata_sql => 'conf/mariadb/table_stress.sql', # rpl_mode # ------------------------------------------- # RQG_RPL_NONE # Run with one server only. No replication of any type at all. rpl_mode => 'none', # # RQG_RPL_STATEMENT # Run with two servers, MariaDB replication and binlog_format=statement. # rpl_mode => 'statement', # RQG_RPL_STATEMENT_NOSYNC # rpl_mode => 'statement-nosync', # # RQG_RPL_MIXED # Run with two servers, MariaDB replication and binlog_format=mixed. # rpl_mode => 'mixed', # RQG_RPL_MIXED_NOSYNC # rpl_mode => 'mixed-nosync', # # RQG_RPL_ROW # Important observation: # 10.4 -> 10.3 failed systematic with Error_code: 1032; handler error HA_ERR_END_OF_FILE # 10.4 -> 10.4 worked # 10.3 -> 10.4 worked # Run with two servers, MariaDB replication and binlog_format=row. # rpl_mode => 'row', # RQG_RPL_ROW_NOSYNC # rpl_mode => 'row-nosync', # # RQG_RPL_GALERA # Unclear if currently used. # Run with n? servers and Galera # rpl_mode => 'galera', # # RQG_RPL_RQG2 # Run with two servers and RQG's builtin statement based replication. # rpl_mode => 'rqg2', # RQG_RPL_RQG3 # Run with three servers and RQG's builtin statement based replication. # rpl_mode => 'rqg3', # sqltracing by RQG # ----------------- # Advantage: # The RQG log content gives you at least some idea which SQL was running when some # replay happened. # Disadvantage: # Higher resource consumption during runtime of the simplifier. # Getting at least some idea which SQL was running when some replay happened isn't bad # but quite frequent such information does not help significant or only a few (the # last ones) statements are already sufficient (== all previous only wasted resources). # I recommend to # - not enable sqltracing here # - perform runs with sqltracing after simplification end if useful at all. # # Print trace message before sending the statement to the server. # sqltrace => undef, # Print trace message after receiving the result or error messages from the server # including error message etc. # sqltrace => 'MarkErrors', mysqld => { 'innodb_adaptive_hash_index' => 'OFF', 'loose-innodb_buffer_pool_instances' => 3, 'loose-innodb-use-atomic-writes' => undef, # 'innodb_log_optimize_ddl' => 'ON', 'plugin-load-add' => 'file_key_management.so', 'loose-file-key-management-filename' => '$RQG_HOME/conf/mariadb/encryption_keys.txt', # 'loose-file-key-management-filename' => '/work/RQG_mleich2/conf/mariadb/encryption_keys.txt', 'loose-innodb-encryption-threads' => 7, # Avoid hitting https://jira.mariadb.org/browse/MDEV-16136 # 'innodb_stats_persistent' => 'off', # Avoid hitting https://jira.mariadb.org/browse/MDEV-16664 'loose_innodb_lock_schedule_algorithm' => 'fcfs', # # In some environment with many parallel RQG runs the following settings are required # for reducing trouble caused by # - shortages of resources # or # - slow responses of clients and servers. # IMHO it is recommended to set values even if the current defaults are already good # enough. Defaults could ge changed in future and than maybe to some unfortunate # direction. # ====================================================================================== # aio is on most boxes/OS a very short resource. # Disabling its use is usually required and prevents valueless starts of RQG runners and # also other ugly effects to be accepted+already known from that reason. # But this implies that aio related code of InnoDB is not covered. 'loose_innodb_use_native_aio' => 0, # # Threads running the queries from YY grammar might frequent lose their connection # (get killed by other threads or reporters or commit/rollback release) and than need to # 1. connect again # 2. run a few initial SQL's before running the mass of YY grammar queries goes on # And in case 1. or 2. fails the RQG core tends to claim STATUS_SERVER_CRASHED, # STATUS_SERVER_CRASHED, STATUS_ENVIRONMENT_FAILURE and similar. This is often a false # alarm in case the timeouts are too short for some heavy loaded box. # 1. Is often a victim of connection related timeouts. # 2. Is often a victim of locking related timeouts and depending on the functionality # within the RQG core we get either some immediate end of the RQG run with # questionable status or the test goes on but the thread has not done things which # are mandatory for the test to work proper. In the second case we could end up with # false positives and similar. # Per my experience the innodb lock and MDL lock timeouts are quite critical. # In case the threads should use small values for these timeout during YY grammar # processing than these timeouts could be set in the rules # query_connect or # thread_connect # of the YY grammar. # # connect_timeout # Time in seconds that the server waits for a connect packet before returning a # 'Bad handshake'. Increasing may help if clients regularly encounter # 'Lost connection to MySQL server at 'X', system error: error_number' type-errors. # Default: 10 'connect_timeout' => 60, # # net_read_timeout # Time in seconds the server will wait for a client connection to send more data before # aborting the read. # Default: 30 'net_read_timeout' => 30, # # net_write_timeout # Time in seconds to wait on writing a block to a connection before aborting the write. # Default: 60 'net_write_timeout' => 60, # # idle_readonly_transaction_timeout # Time in seconds that the server waits for idle read-only transactions before killing # the connection. If set to 0, the default, connections are never killed. # Default Value: 0 'loose-idle_readonly_transaction_timeout' => 0, # # idle_transaction_timeout # Time in seconds that the server waits for idle transactions before killing the # connection. If set to 0, the default, connections are never killed. # Default Value: 0 'loose-idle_transaction_timeout' => 0, # # idle_write_transaction_timeout # Time in seconds that the server waits for idle read-write transactions before killing # the connection. If set to 0, the default, connections are never killed. # Default Value: 0 'loose-idle_write_transaction_timeout' => 0, # # innodb_lock_wait_timeout # Time in seconds that an InnoDB transaction waits for an InnoDB row lock (not table # lock) before giving up with the error # ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting trans... # When this occurs, the statement (not transaction) is rolled back. The whole # transaction can be rolled back if the innodb_rollback_on_timeout option is used. # Increase this for data warehousing applications or where other long-running operations # are common, or decrease for OLTP and other highly interactive applications. # This setting does not apply to deadlocks, which InnoDB detects immediately, rolling # back a deadlocked transaction. # 0 (from MariaDB 10.3.0) means no wait. See WAIT and NOWAIT. # Default Value: 50 'innodb-lock-wait-timeout' => 50, # # interactive_timeout # Time in seconds that the server waits for an interactive connection (one that connects # with the mysql_real_connect() CLIENT_INTERACTIVE option) to become active before # closing it. # Default Value: 28800 # AFAIK RQG will not initiate such connections. 'interactive_timeout' => 28800, # # lock_wait_timeout # Timeout in seconds for attempts to acquire metadata locks. Statements using metadata # locks include FLUSH TABLES WITH READ LOCK, LOCK TABLES, HANDLER and DML and DDL # operations on tables, stored procedures and functions, and views. The timeout is # separate for each attempt, of which there may be multiple in a single statement. # 0 (from MariaDB 10.3.0) means no wait. See WAIT and NOWAIT. # Default Value: # 86400 (1 day) >= MariaDB 10.2.4 # 31536000 (1 year) <= MariaDB 10.2.3 'lock-wait-timeout' => 86400, # # table_lock_wait_timeout # Unused, and removed in MariaDB/MySQL 5.5.3 # Default Value: 50 # IMHO its better to set it because we do not know which MariaDB version RQG might meet. 'loose-table_lock_wait_timeout' => 50, # # wait_timeout # Time in seconds that the server waits for a connection to become active before # closing it. The session value is initialized when a thread starts up from either the # global value, if the connection is non-interactive, or from the interactive_timeout # value, if the connection is interactive. # Default Value: 28800 'wait_timeout' => 28800, # # slave_net_timeout # Time in seconds for the slave to wait for more data from the master before considering # the connection broken, after which it will abort the read and attempt to reconnect. # The retry interval is determined by the MASTER_CONNECT_RETRY open for the # CHANGE MASTER statement, while the maximum number of reconnection attempts is set by # the master-retry-count variable. # The first reconnect attempt takes place immediately. # Default Value: # 60 (1 minute) (>= MariaDB 10.2.4) # 3600 (1 hour) (<= MariaDB 10.2.3) 'slave_net_timeout' => 60, # # # This makes the simplification process faster. 'log-output' => 'none', }, }, # grammar_flags #-------------- # You could set "grammar_flags" to GRAMMAR_FLAG_COMPACT_RULES so that rules such as # rule: a | a | a | a | a | a | b ; are compressed to rule: a | b # before simplification. # The impact of that at test runtime is # Known (irrelevant up till big) disadvantage of that at grammar runtime # - non compressed: Generation of 86% 'a' and 14% 'b'. # - compressed: Generation of 50% 'a' and 50% 'b'. # regarding # - likelihood to replay some desired outcome # Jumps to the better are possible too but less likely. # - evolution of resource consumption of tests at runtime. # Jumps to the better are possible too but less likely. # The rqg_batch resource control is good in handling that some more and more bigger fraction # of concurrent tests becomes critical regarding resource consumption. # But meeting some 100% of all concurrent tests are critical from the begin on might # - exceed the capabilities of resource control to avoid disasters # - not exceed the capabilities but cause a too high fraction of to be stopped runs # # Impact on the maximum number of shrink attempts: # The old grammar simplifier tried to remove any single component of the grammar rule # --> in maximum two attempts with the compressed rule # --> in maximum seven attempts with the non compressed rule # So GRAMMAR_FLAG_COMPACT_RULES gave often in sum (advantage+disadvantage) some benefit. # # The current (new) grammar simplifier determines the unique components ('a' and 'b') and tries # than to remove all occurence of some unique component. # --> In maximum two attempts including that the disadvantage described above cannot happen. # # Recommendation: # Do NOT set GRAMMAR_FLAG_COMPACT_RULES. Of course feel free to experiment. # # grammar_flags => +GRAMMAR_FLAG_COMPACT_RULES, # trials #------- # Maximum number of finished RQG runs which did not replay before the simplifier gives up # with that simplification phase or the complete process. # # Phase Give up after a queue of finished and non replaying attempts # PHASE_FIRST_REPLAY $trials and abort the simplifier run # PHASE_THREAD1_REPLAY $trials and switch to the next phase # PHASE_FINAL_REPLAY $trials and report that, give summary and exit # # All other simplification phases work roughly "open end" and do not use the value in $threads # at all. # # Given the fact that certain desired outcomes are often not that likely to reproduce even # if the grammar is capable to do it use a value between 30 and 50. trials => 60, # search_var_size #---------------- # Number of bytes (counted from the end of the output file) to be used during # search for expected_output We suck the last "search_var_size" Bytes of the file # to be searched into a variable. # A too huge "search_var_size" could cause problems. # The relevant zone within the file is maybe # - smaller # If our search pattern is unfortunately a bit unspecific and if it # could also occur within irrelevant zones of the file than we might # get false positives. Decreasing "search_var_size" might help. # - bigger # We might get false negatives. Increasing "search_var_size" might # help but I am unsure if any OS and PERL implementation supports # such a monstrous variable. search_var_size => 30000000, # run_id # ------ # run_id can be assigned on cammand line to rqg_batch but it cannot be set in the config file here. # It is mentioned here because it plays an important role in the explanation of the next parameters # 'vardir' and 'workdir'. # rqg_batch.pl itself assigns the number of seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC) # to it. # This roughly guarantees that consecutive runs of # - tools managing batches of RQG runs like rqg_batch.pl # - using the same values for workdir and vardir # will not finally use the same workdirs and vardir for their run. # So collisions during runtime and mangling of historic results should be mostly impossible. # # # vardir #------- # "Server activity" should happen in the "vardir" of the rqg_batch run. # And that gets created as subdirectory of the directory assigned here. # Example: /dev/shm/vardir/ --> /dev/shm/vardir/1545341608 # Important points are: # - free space within the filesystem # - performance of the filesystem # Simplification gets usually a significant speed up if we could use a memory based filesystem # like tmpfs. # # Default: /dev/shm/vardir # vardir => '/dev/shm/vardir', # workdir #--------------- # Grammars, RQG logs etc. of the simplification process get stored within the workdir of the # rqg_batch run/the grammar simplification process. # And that gets created as subdirectory of the directory assigned here. # Example: / --> ./storage/1545341608 # # Default: ./storage # workdir => './storage' }