| Bug #58745 | MTR spends long time checking for warnings | ||
|---|---|---|---|
| Submitted: | 5 Dec 2010 22:56 | Modified: | 2 May 2011 14:56 |
| Reporter: | Elena Stepanova | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | Tools: MTR / mysql-test-run | Severity: | S5 (Performance) |
| Version: | 5.5.8 | OS: | Any |
| Assigned to: | Bjørn Munch | CPU Architecture: | Any |
[6 Dec 2010 9:20]
Bjørn Munch
Some speedup may be possible, but it's implemented in a way which is not very optimal, doing the matching against suppressed patterns in SQL. I'm not sure it will be more optimal in Perl though; the number of comparisons needed is number of warnings x number of suppress patterns. A workaround for a specific test could be to add --testcase-timeout=60 to <test>-master.opt; this will increase the check warnings timeout to 1/10 of that, or 6 minutes. Adjust according to your needs.
[2 May 2011 14:56]
Paul DuBois
Changes to test suite. No changelog entry needed.

Description: I have a test case which makes server write a considerable number of warnings in the error log (e.g 5,000). It is by design. While the test case itself takes about nothing, the total time MTR spends running it is ~60 sec. The servers were restarted 0 times Spent 0.000 of 60 seconds executing testcases With nowarnings it takes < 10 sec. If the number of warnings is greater, the time grows too. It can also fail with Timeout for 'check warnings' expired after 90 secondsmysqltest failed but provided no output (quoted literally, no end-of-line or a space) How to repeat: --source include/have_log_bin.inc SET binlog_format=STATEMENT; --disable_warnings DROP TABLE IF EXISTS t, t2; CREATE TABLE t ( i INT ) ENGINE = MyISAM; CREATE TABLE t2 ( i INT ) ENGINE = InnoDB; INSERT INTO t VALUES (1); BEGIN; --disable_query_log let $num=5000; while ($num) { INSERT INTO t2 SELECT * FROM t; dec $num; } --enable_query_log COMMIT; DROP TABLE t, t2; --exit Suggested fix: While 5,000 warnings is a fairly big amount, 50 seconds to process them seems too long, maybe there is a way to optimize it.