The patch also fixes a race in rpl_stop_slave.test.
On machines with lots of CPU and memory, something like `mtr --parallel=10`
can speed up the test suite enormously. However, we have a few test cases
that run for long (several minutes), and if we are unlucky and happen to
schedule those towards the end of the test suite, we end up with most
workers idle while waiting for the last slow test to end, significantly
delaying the finish of the entire suite.
Improve this by marking the offending tests as taking "long", and trying
to schedule those tests early. This reduces the time towards the end of
the test suite run where some workers are waiting with nothing to do for
the remaining workers each to finish their last test.
Also, the rpl_stop_slave test had a race which could cause it to take
a 300 seconds debug_sync timeout; this is fixed.
Testing on a 4-core 8GB machine, this patch speeds up the test suite with
around 30% for --parallel=10 (debug build), allowing to run the entire
suite in 5 minutes.
Under a debug run, the trace file grows to a few gigabytes.
Under valgrind, takes more then 20 minutes due to the high
number of insert statements.
mysql-test/t/multi_update2.test:
Skip under --valgrind and --debug.
Under a debug run, the trace file grows to a few gigabytes.
Under valgrind, takes more then 20 minutes due to the high
number of insert statements.
mysql-test/t/multi_update2.test:
Skip under --valgrind and --debug.
The test itself is not faulty. The testcase timeout
problem happens if this IMHO mid size resource
(space in vardir, virtual memory, amount of disk I/O)
consuming test meets a weak (excessive disk I/O caused
by parallel applications or paging) testing box.
The modifications:
- Move the most time and disk I/O consuming subtest
for Bug 1820 into its own script (multi_update2)
This will reduce the likelihood that we exceed the
testcase timeout.
- Replace error numbers with error names
- Minor improvements of the formatting
-
