[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...
/cc alerner

f5dd5e428719 Enterprise Linux 64-bit Amazon AMI sharding_auth
http://buildlogs.mongodb.org/mci_0.9_enterprise_linux_64_amazon_ami/builds/1325/test/sharding_auth_0/inTiming.js

Unsharded $in query ran in 4
Sharded $in query ran in 40
assert failed : Sharded query is more than 10 times as slow as unsharded query
Error: Printing Stack Trace
    at printStackTrace (src/mongo/shell/utils.js:38:15)
    at doassert (src/mongo/shell/assert.js:6:5)
    at assert (src/mongo/shell/assert.js:14:5)
    at /data/mci/git@github.commongodb/mongo.git/master/jstests/sharding/inTiming.js:31:1
2013-10-14T00:25:47.273+0000 assert failed : Sharded query is more than 10 times as slow as unsharded query at src/mongo/shell/assert.js:7
failed to load: /data/mci/git@github.commongodb/mongo.git/master/jstests/sharding/inTiming.js



 Comments   
Comment by auto [ 16/Oct/13 ]

Author:

{u'username': u'hkhalsa', u'name': u'Hari Khalsa', u'email': u'hkhalsa@10gen.com'}

Message: SERVER-11168 remove inTiming.js tests - flaky
Branch: master
https://github.com/mongodb/mongo/commit/94ce941611abf2fd3826936a90d93b09e483d99c

Comment by auto [ 16/Oct/13 ]

Author:

{u'username': u'hkhalsa', u'name': u'Hari Khalsa', u'email': u'hkhalsa@10gen.com'}

Message: Revert "SERVER-11168 go to EOF if collection doesn't exist or has no docs" breaks arrayfind7.js

This reverts commit 7a4dfa13328f47eb1fa4e5ef5de264883366571f.
Branch: master
https://github.com/mongodb/mongo/commit/b25cce86256206a0fd3d136c5b5e13dbf04476ba

Comment by auto [ 15/Oct/13 ]

Author:

{u'username': u'hkhalsa', u'name': u'Hari Khalsa', u'email': u'hkhalsa@10gen.com'}

Message: SERVER-11168 go to EOF if collection doesn't exist or has no docs
Branch: master
https://github.com/mongodb/mongo/commit/7a4dfa13328f47eb1fa4e5ef5de264883366571f

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
Author: Hari Khalsa <hkhalsa@10gen.com>
Date: Sat Oct 12 09:45:39 2013 -0400

SERVER-10026 enable new query system by default

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
d1c2ae72c482 C++11 Ubuntu 1204 64-bit sharding_auth
d1c2ae72c482 Solaris 64-bit sharding

Comment by Matt Kangas [ 14/Oct/13 ]

Recurred:

3f2c4c4afd01 Linux 32-bit sharding (logfile)
3f2c4c4afd01 Enterprise Ubuntu 1204 64-bit sharding_auth (logfile)
3f2c4c4afd01 Solaris 64-bit sharding (logfile)
3f2c4c4afd01 Windows 64-bit DEBUG sharding

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.

Generated at Thu Feb 08 03:25:05 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.