Details
-
New Feature
-
Resolution: Won't Fix
-
Critical - P2
-
None
-
2.6.1
-
None
-
Sharding
Description
Shows up as a performance degradation for applications that use w:0 and getLastError in a sharded environment when going from 2.4 to 2.6:
To reproduce: create a collection, mongodump, mongorestore via mongos to single-shard cluster (single mongod, single config server). Doesn't seem to matter if collection is sharded or not.
Here are some numbers for one data set:
2.4.10, standalone 26s
|
2.6.1, standalone 26s
|
2.4.10, 1x shard, 1x mongos, sharded 58s
|
2.6.1, 1x shard, 1x mongos, sharded 352s
|
Another data set, showing that sharded or unsharded shows same degradation:
2.4.10, standalone 5s
|
2.6.1, standalone 5s
|
2.4.10, 1x shard, 1x mongos, unsharded 5s
|
2.6.1, 1x shard, 1x mongos, unsharded 45s
|
2.4.10, 1x shard, 1x mongos, sharded 8s
|
2.6.1, 1x shard, 1x mongos, sharded 52s
|
Attachments
Issue Links
- is duplicated by
-
SERVER-22260 Support async w:0 mongos writes
-
- Closed
-
- is related to
-
DOCS-3456 mongodb tools and clients in sharded environment for 2.6 need to be updated to new bulk write operations to avoid performance degradation
-
- Closed
-
-
TOOLS-159 Tools should use (batch) write commands
-
- Closed
-
- related to
-
PYTHON-1069 command not listening to writeconcern
-
- Closed
-