| Bug #32699 | test timeouts too small on 'vm-win2003-32-a' and 'vm-win2003-64-b' | ||
|---|---|---|---|
| Submitted: | 25 Nov 2007 12:30 | Modified: | 12 Mar 2009 14:18 |
| Reporter: | Ingo Strüwing | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | Tests: Server | Severity: | S7 (Test Cases) |
| Version: | 6.0.4 | OS: | Any |
| Assigned to: | Timothy Smith | CPU Architecture: | Any |
| Tags: | pbfail | ||
[25 Nov 2007 12:30]
Ingo Strüwing
[25 Nov 2007 12:36]
Ingo Strüwing
Happens also on 'powermacg5'. Example log for a test case timeout: https://intranet.mysql.com/secure/pushbuild/getlog.pl?dir=mysql-6.0&entry=dfischer@pippilo... Example log for test suite timeout: https://intranet.mysql.com/secure/pushbuild/getlog.pl?dir=mysql-6.0-engines&entry=rkalimul...
[28 Jan 2008 15:59]
Patrick Crews
After discussion with some developers, two possible causes have been identified 1) Limited resources of the Virtual Machine - Solution: alter the VM to increase the memory, etc that is available to it. Will discuss this with the Build team 2) Problem with VM itself. There are some possible I/O issues in some of the more complicated tests. This seems less likely -- would like to try the solution for #1 first. Solution: move to actual Windows boxes rather than VM's. Since the test timeouts seem to be random, it is hard to attribute this to a poorly written test.
[28 Jan 2008 16:42]
Ingo Strüwing
Why not just: ===== mysql-test/mysql-test-run.pl 1.162 vs edited ===== --- 1.162/mysql-test/mysql-test-run.pl 2007-12-21 10:28:03 +01:00 +++ edited/mysql-test/mysql-test-run.pl 2008-01-28 17:39:46 +01:00 @@ -244,8 +244,8 @@ our $opt_sleep; our $opt_testcase_timeout; our $opt_suite_timeout; -my $default_testcase_timeout= 15; # 15 min max -my $default_suite_timeout= 180; # 3 hours max +my $default_testcase_timeout= 30; # 30 min max +my $default_suite_timeout= 360; # 6 hours max our $opt_start_and_exit; our $opt_start_dirty;
[8 Feb 2008 0:36]
Patrick Crews
Gathered performance logs for vm-win2003-64-b. WIll attempt to correlate a test timeout with a VM issue such as high CPU utilization, memory usage, etc. If no correlation can be found will need to look at VM host performance or possibly moving to Native Windows hosts. Did not see any machine performance issues which would indicate timeouts due to VM setup while manually observing VM behavior (during multiple build / test cycles)
[12 Mar 2009 14:18]
Timothy Smith
Not relevant anymore.
[12 Mar 2009 15:14]
Ingo Strüwing
Why? Did the machines become faster? Do we test on faster machines?
[13 Mar 2009 0:24]
Timothy Smith
Looking at current test runs for mysql-5.1: https://intranet.mysql.com/secure/pushbuild/showdir.pl?dir=bzr_mysql-5.1 There aren't any more sporadic timeout problems on the machines in question. AFAIK the machines themselves have not changed; the new MTR, and the massive amounts of work done to improve test case quality, have probably had the greatest effect here.
[13 Mar 2009 0:32]
Timothy Smith
Looking at current test runs for mysql-6.0: https://intranet.mysql.com/secure/pushbuild/showdir.pl?dir=bzr_mysql-6.0 AFAIK the machines themselves have not changed; the new MTR, and the massive amounts of work done to improve test case quality, have probably had the greatest effect here. Sporadic timeouts are much less prevelant, and almost always not repeated when a test case is run again by MTR, so it's not a problem for test result interpretation. Finally, PB2 won't be using vmware boxes for test hosts, so any problems which may be due to our particular vmware hosts are not of long term concern.
