[SERVER-5737] Mongorestore to mongos when using auth is slow. Created: 01/May/12 Updated: 15/Aug/12 Resolved: 01/May/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Performance, Tools |
| Affects Version/s: | 2.0.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Jonathan Schneider | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
CentOS 6.2 x86_64 - Runnig on VMWare ESX |
||
| Issue Links: |
|
||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
I have observed and been able to duplicate mongorestore running very slowely when restoring data to a sharded cluster while using auth. I setup a simple test cluster for the below examples:
After Auth: (slow, about 3MB/sec)
Restore to replica set primary with auth: (fast, about 10MB/sec)
This was a simple test setup that only contained 1 shard and 2 replica set members, the disparity in speed difference seems to be larger with a larger cluster. In our prod cluster mongorestore runs closer to 1MB/sec with auth against a mongos instance and 50MB/sec run directly against the primary server in one shard. |
| Comments |
| Comment by Jonathan Schneider [ 01/May/12 ] |
|
Yes, sounds good, thanks. |
| Comment by Eric Milkie [ 01/May/12 ] |
|
I marked |
| Comment by Jonathan Schneider [ 01/May/12 ] |
|
This may have been fixed in https://jira.mongodb.org/browse/SERVER-5405 I tested with 2.1.1 latest nightly and the problem does not exist. Would love to see a 2.0 backport. |
| Comment by Jonathan Schneider [ 01/May/12 ] |
|
I should add that during the slow restores nothing is pinned anywhere, iostat reveals quiet disks, top reveals quiet cpu's on both the mongos instance and the primary server. Nothing seems to be causing a bottleneck anywhere. When run without auth the mongod instance on the primary server becomes pinned clearly being the bottleneck to faster restore speed. |
| Comment by Jonathan Schneider [ 01/May/12 ] |
|
I believe this is an important issue as it will make restoring a database in the event of a problem a much longer process than it should be. I needed to restore a 20GB database on prod and it took 12 hours, on my test setup without auth it did it in less than 30 minutes. |