Merge lp:~stewart/percona-xtrabackup/2.0-parallel-test into lp:percona-xtrabackup/2.0
Status: | Merged |
---|---|
Approved by: | Alexey Kopytov |
Approved revision: | no longer in the source branch. |
Merged at revision: | 493 |
Proposed branch: | lp:~stewart/percona-xtrabackup/2.0-parallel-test |
Merge into: | lp:percona-xtrabackup/2.0 |
Diff against target: |
555 lines (+445/-12) 10 files modified
test/inc/common.sh (+1/-0) test/run.sh (+14/-0) test/t/xb_incremental_compressed.inc (+0/-5) test/t/xb_incremental_compressed_16kb.sh (+2/-0) test/t/xb_incremental_compressed_1kb.sh (+2/-0) test/t/xb_incremental_compressed_2kb.sh (+2/-0) test/t/xb_incremental_compressed_4kb.sh (+2/-0) test/t/xb_incremental_compressed_8kb.sh (+2/-0) test/testrun.c (+405/-0) test/testrun.sh (+15/-7) |
To merge this branch: | bzr merge lp:~stewart/percona-xtrabackup/2.0-parallel-test |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Alexey Kopytov (community) | Approve | ||
Review via email: mp+142414@code.launchpad.net |
This proposal supersedes a proposal from 2012-11-08.
Description of the change
Introduce a parallel test runner to XtraBackup.
This *dramatically* reduces the amount of time a build through Jenkins takes. An individual build+test can now be about 10 minutes instead of 30 to 50 minutes. Multiplied by 100 or so, this is a big improvement.
I've made the parallel test runner execute using exactly the same commands as the non-parallel one so that the jenkins jobs don't require switching.
The parallel runner is just simple straight C and likely builds on any POSIX system released in the past twenty years.
New Jenkins run (with fix for test suite killing unrelated processes):
http://
Once I've merged in the other few fixes for running tests, I'll do another jenkins run.
Note that I'm still tweaking the automatic "how many concurrent jobs to execute" algorithm... I've found 1.0 * NRCPUS to be better than 1.5 * NRCPUS on our jenkins cluster, but it seems as though we may have hit a couple of timeouts still. This could be rectified by either increasing the timeout (10 minutes) or reducing parallelism.