[SERVER-5714] Nicer behavior of dbstats call on database with large nssize Created: 26/Apr/12 Updated: 06/Dec/22 Resolved: 14/Sep/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | MMAPv1, Performance, Storage |
| Affects Version/s: | 2.0.4, 2.1.0 |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Jason R. Coombs | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Won't Fix | Votes: | 3 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Storage Execution
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
If one has a database with thousands of collections (each with a few indexes), it has a very large nssize. The docs indicate that this might be a problem when they say
It's not obvious from this statement, but if you run dbstats on a database with a very large nssize, it can literally take you database offline for minutes our hours as it did in our environment:
One of our devs added this query to part of our database browser not realizing the impact it would have on this particular database. When he browsed to our production database, it took services down for 15 minutes (882 seconds at the time we read that log entry). We ran into this problem when we launched MMS against our servers. We've been banned from using MMS as a result. There should be a way to avoid these situations at the database level (rather than by patching MMS, patching our client apps, and patching each and every developer to remember not to invoke this operation). A few options:
If one could protect our database from this, it would mean we can prevent this situation from other inadvertent or intentional DoS in the future, regardless of where the request comes from. |
| Comments |
| Comment by Jason R. Coombs [ 23/Oct/17 ] | ||||||||||||||||||||||||||
|
I expect this issue only applies to MMAPv1, as WiredTiger has more granular locking. I created this test:
This test passes on MongoDB 3.4.9 using default parameters (WiredTiger for storage), meaning db.stats completes in under 1 second with 10000 collections in existence. | ||||||||||||||||||||||||||
| Comment by Eric Milkie [ 23/Oct/17 ] | ||||||||||||||||||||||||||
|
This ticket only involves MMAPv1, as it talks about mmap-specific structures and behaviors. There could be a similar issue for WiredTiger regarding the "dbStats" command and databases with large numbers of collections, but I don't believe a JIRA ticket exists. | ||||||||||||||||||||||||||
| Comment by Jeff Widman [ 23/Oct/17 ] | ||||||||||||||||||||||||||
|
Does this affect WiredTiger or only MMAPv1? |