[SERVER-10726] memory.js taking 7+ hours on Linux 64 DEBUG Created: 10/Sep/13 Updated: 28/Oct/15 Resolved: 19/Sep/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | JavaScript, Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | 2.5.3 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Ian Whalen (Inactive) | Assignee: | Andrew Morrow (Inactive) |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
SlowNightly tests were never run on Buildbot's Linux 64 DEBUG builder, so this is a newly discovered issue. It looks like memory.js takes around 440 minutes on MCI on a regular basis which, when added to the rest of the slowNight suite, adds up to more than 12 hours. This causes the suite to fail. And example of a log output for this test taking too long: |
| Comments |
| Comment by Andrew Morrow (Inactive) [ 19/Sep/13 ] |
|
The most recent run of memory.js took less than 40 minutes: http://buildlogs.mongodb.org/mci_0.9_linux_64_debug/builds/869/test/slow_nightly_tests_0/memory.js |
| Comment by auto [ 18/Sep/13 ] |
|
Author: {u'username': u'ehershey', u'name': u'Ernie Hershey', u'email': u'github@ernie.org'}Message: Merge pull request #5 from acmorrow/
|
| Comment by auto [ 18/Sep/13 ] |
|
Author: {u'username': u'ehershey', u'name': u'Ernie Hershey', u'email': u'github@ernie.org'}Message: Merge pull request #5 from acmorrow/
|
| Comment by auto [ 18/Sep/13 ] |
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}Message: |
| Comment by auto [ 18/Sep/13 ] |
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}Message: |
| Comment by Andrew Morrow (Inactive) [ 17/Sep/13 ] |
|
Deployment of this is held up behind finding a way to update the v8 SConscript to suppress certain new warning classes that only show up when both optimization and debugging are enabled, in a way that will work across a large space of compiler classes and versions. Unfortunately, in that context, we don't have access to addFlagIfSupported in the top level SConstruct, nor do we have an easy hook into the configure mechanism. |
| Comment by Eliot Horowitz (Inactive) [ 17/Sep/13 ] |
|
Drew - agree. That looks good and we should switch builders. |
| Comment by Andrew Morrow (Inactive) [ 17/Sep/13 ] |
|
Running memory.js on my local linux machine: mongod built with --dbg=off --opt=on: This lines up pretty reasonably with what we observe on MCI: http://buildlogs.mongodb.org/mci_0.9_linux_64/builds/864/test/slow_nightly_tests_0/memory.js mongod built with --dbg=on --opt=on: Not bad! If we like this, and I think we do, I'll work with Ernie and the MCI folks to get the DEBUG MCI builders running with --opt=on in addition to --dbg=on. |
| Comment by auto [ 16/Sep/13 ] |
|
Author: {u'username': u'acmorrow', u'name': u'Andrew Morrow', u'email': u'acm@10gen.com'}Message: Introduce new flags --dbg and --opt which permit independent control over optimization and The old flags are still supported in a legacy mode for --d and --dd builds, cannot be mixed For builds specifying none of --dbg, --opt, --d, or --dd, there should be no behavior change, |
| Comment by Ian Whalen (Inactive) [ 13/Sep/13 ] |
|
First pass at a solution will likely involve separating into separate flags the 'disable optimizations' and 'enable DEBUG mode' changes implied by the --dd flag in Scons. |
| Comment by Eliot Horowitz (Inactive) [ 10/Sep/13 ] |
|
slowNightly should not run with debug. will never work |