Operational Defect Database

BugZero found this defect 2478 days ago.

MongoDB | 383511

[SERVER-29196] collection cloner only sets batchSize on initial find, not getMores

Last update date:

10/30/2023

Affected products:

MongoDB Server

Affected releases:

No affected releases provided.

Fixed releases:

3.5.9

Description:

Info

If you don't specify a batchSize for a getMore, it will revert to the default size. It doesn't inherit the batchSize from the initial find.

Top User Comments

xgen-internal-githook commented on Wed, 7 Jun 2017 14:49:08 +0000: Author: {u'name': u'Jason Chan', u'email': u'jason.chan@mongodb.com'} Message: SERVER-29196 Set batchSize for getMores in CollectionCloner Branch: master https://github.com/mongodb/mongo/commit/bca18b7766f139c9239c727f7fd327458103a095 xgen-internal-githook commented on Tue, 6 Jun 2017 18:23:05 +0000: Author: {u'name': u'Jason Chan', u'email': u'jasonchan@Jasons-MacBook-Pro.local'} Message: SERVER-29196 set batchSize for getMores in collection cloner Branch: SERVER-29196_collection_cloner_getmore_batchsize https://github.com/mongodb/mongo/commit/b577ea7d8a3b9ee65626891779a7eb3ca6354aaf milkie commented on Tue, 16 May 2017 13:10:06 +0000: I'm hoping that our initial sync perf tests will show some change after this is fixed. dan@10gen.com commented on Mon, 15 May 2017 22:13:13 +0000: Not sure if this will show up in practice, but larger batch sizes have the potential to make intra-cluster compression (on by default in 3.6) more efficient as well. milkie commented on Mon, 15 May 2017 20:27:00 +0000: Yes, that hardcoded value was explicitly written as part of the initial sync project; it was just overlooked that we didn't apply the value to both find's and getMore's. I came across this when I tried to make the batchSize very small to reproduce a bug – I was surprised to discover that it didn't actually work for getMores. spencer commented on Mon, 15 May 2017 20:14:49 +0000: So we don't actually expose the batch size at all, we just hard code it here. So the question becomes whether we believe this hard-coded value to be meaningful and likely to be better than the default for the majority of workloads. I think the answer is probably yes - given that latency doesn't really matter for initial sync, only throughput matters, that suggests that bigger batch sizes are likely to perform better. milkie commented on Mon, 15 May 2017 19:22:23 +0000: The impact is that the getMore efficiency might be greatly improved with a larger batch size. This would translate to less load on the sync source as well as better throughput for high latency, high bandwidth connections. spencer commented on Mon, 15 May 2017 19:20:07 +0000: milkie, what's the impact of this? The collection cloner is only for initial sync - do we even allow users to specify non-default batch sizes for initial sync?

Additional Resources / Links

Share:

BugZero Risk Score

Coming soon

Status

Closed

Have you been affected by this bug?

cost-cta-background

Do you know how much operational outages are costing you?

Understand the cost to your business and how BugZero can help you reduce those costs.

Discussion

Login to read and write comments.

Have you ever...

had your data corrupted from a

VMware

bug?

Search:

...