[SERVER-11168] sharding/inTiming.js failed on Enterprise Linux 64-bit Amazon AMI Created: 14/Oct/13 Updated: 11/Jul/16 Resolved: 16/Oct/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | 2.5.3 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Matt Kangas | Assignee: | Greg Studer |
| Resolution: | Done | Votes: | 0 |
| Labels: | buildbot | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Participants: |
| Description |
|
The previous commit tested green. This is precisely the first failure on this builder. Interesting error message... f5dd5e428719 Enterprise Linux 64-bit Amazon AMI sharding_auth
|
| Comments |
| Comment by auto [ 16/Oct/13 ] |
|
Author: {u'username': u'hkhalsa', u'name': u'Hari Khalsa', u'email': u'hkhalsa@10gen.com'}Message: |
| Comment by auto [ 16/Oct/13 ] |
|
Author: {u'username': u'hkhalsa', u'name': u'Hari Khalsa', u'email': u'hkhalsa@10gen.com'}Message: Revert " This reverts commit 7a4dfa13328f47eb1fa4e5ef5de264883366571f. |
| Comment by auto [ 15/Oct/13 ] |
|
Author: {u'username': u'hkhalsa', u'name': u'Hari Khalsa', u'email': u'hkhalsa@10gen.com'}Message: |
| Comment by hari.khalsa@10gen.com [ 15/Oct/13 ] |
|
I am trying to figure out exactly how we are slower but this is a bad test. |
| Comment by Greg Studer [ 15/Oct/13 ] |
|
Can verify on my box that a noticeable explain() slowdown happens at: commit 45a9b3929a1f8ce20188e0979be9fae6ac67fd2a Again, it's not clear this is actually something we care about, since it's an empty collection. |
| Comment by Greg Studer [ 15/Oct/13 ] |
|
Current hypothesis is that the issue here isn't related to sharded/unsharded collections - the sharded collection differs from the unsharded collection because an index is actually built on "shardCollection". Normally this would make the sharded query faster, but because both collections are empty the BasicCursor can just return immediately without testing 500 bounds. On my own system I can see a noticeable difference between last week and this week in explain() - trying now at the "turn-on" point for new queries. If hari.khalsa@10gen.com can verify this is plausible, recommend we just kill this test - it doesn't do what it says it does and doesn't give us any useful debugging information. |
| Comment by hari.khalsa@10gen.com [ 15/Oct/13 ] |
|
I'll take a look to see if query is doing anything particularly dumb after I wrap up the geo break... |
| Comment by Matt Kangas [ 15/Oct/13 ] |
|
More data points: d1c2ae72c482 C++11 Ubuntu 1204 64-bit sharding |
| Comment by Matt Kangas [ 14/Oct/13 ] |
|
Recurred: 3f2c4c4afd01 Linux 32-bit sharding (logfile) |
| Comment by Matt Kangas [ 14/Oct/13 ] |
|
hari.khalsa@10gen.com - noted. I'll close this ticket tomorrow if I don't see it recur. |
| Comment by hari.khalsa@10gen.com [ 14/Oct/13 ] |
|
kangas Note that the test passed in the latest build. |
| Comment by hari.khalsa@10gen.com [ 14/Oct/13 ] |
|
Test is inherently flaky as it's asserting on time. alerner I'm fine with increasing the time diff. but I have no insight from the sharding perspective. |