[DOCS-91] Table of limits Created: 15/Dec/11  Updated: 29/Nov/12  Resolved: 12/Oct/12

Status: Closed
Project: Documentation
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Richard Kreuter (Inactive) Assignee: Sam Kleinman (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:
Days since reply: 11 years, 18 weeks, 1 day ago

 Description   

It would be handy if we documented any and all system limits in a single place. Examples:

  • maximum document size
  • maximum number of indexes per collection
  • maximum namespace length
  • maximum number of fields per index
  • maximum number of members in a replica set (voting and non-voting)

probably there are lots more around.

Additionally, certain quantities don't have limits per se, but are a function of something else about the installation, so it'd be useful to give approximate formulas for an installation's limit on things. Examples:

  • maximum number of namespaces (a function of the .ns file size)
  • maximum dataSize (an approximate function of the machine architecture and whether journaling is enabled)
  • maximum number of chunks per sharded collection (this is mostly hypothetical)
  • maximum sharded collection size in bytes (another hypothetical quantity)


 Comments   
Comment by auto [ 17/Oct/12 ]

Author:

{u'date': u'2012-10-16T17:18:48-07:00', u'email': u'samk@10gen.com', u'name': u'Sam Kleinman'}

Message: DOCS-91: corrections to limits
Branch: master
https://github.com/mongodb/docs/commit/8e6375b3a8c7d39899d57e4cf7398af9abaf8a52

Comment by Sam Kleinman (Inactive) [ 12/Oct/12 ]

Richard,

Could you please close to confirm.

I've intentionally not included limits and thresholds which are hypothetical (and untested,) or controlled by a number of factors including platform specific configurations.

Feel free to re-open if there's a large gap of concrete limits. Or open smaller specific tickets about new limits that need to be included.

Cheers,
sam

Comment by auto [ 12/Oct/12 ]

Author:

{u'date': u'2012-10-12T10:59:09-07:00', u'email': u'samk@10gen.com', u'name': u'Sam Kleinman'}

Message: DOCS-91 organization and additional facts
Branch: master
https://github.com/mongodb/docs/commit/35fe18f209bc22538b8ba6242f1146fca23c44e5

Comment by auto [ 12/Oct/12 ]

Author:

{u'date': u'2012-10-12T08:31:05-07:00', u'name': u'Sam Kleinman', u'email': u'samk@10gen.com'}

Message: DOCS-91 providing better indexing.
Branch: master
https://github.com/mongodb/docs/commit/7dff238cf6509664cc30169be5bcc3d4019106ad

Comment by Richard Kreuter (Inactive) [ 05/Jun/12 ]

Not quite limits, but related (in my head):

  • restrictions on names of databases (e.g., no dots, & database names are case-sensitive only if the fs is)
  • restrictions on names of collections (if there are any)
  • restrictions on characters in field names (e.g., no dots or dollarsigns)
Comment by Sam Kleinman (Inactive) [ 30/Apr/12 ]

http://docs.mongodb.org/manual/reference/limits/

Perhaps it would be good, to meet up in person to get some of the reset of these values and limits nailed down.

Comment by Sam Kleinman (Inactive) [ 23/Jan/12 ]

An in memory sort without an index must complete using less than 32 megabytes of RAM, or the sort is stopped. (source: scott in training)

Comment by Richard Kreuter (Inactive) [ 23/Jan/12 ]

More limits!

  • Maximum number of documents we'll sort in memory (there's some error message about "too many documents to sort without an index" when we exceed this limit).
  • If there are limits on the number of documents we'll de-duplicate for multi-key index queries or $or queries, then those, too.
Comment by Richard Kreuter (Inactive) [ 11/Jan/12 ]

Another limit! The maximum length of a query's JSON representation that we'll show in db.currentOp, the system profiler, the log file, etc.

Comment by Richard Kreuter (Inactive) [ 19/Dec/11 ]

More limits!

  • how many megabytes we're willing to sort in memory (for scanAndOrder queries)
  • if there's a limit on the maximum number of documents we deduplicate for multikey and $or processing, then that
  • maximum index key length
  • maximum $in list length

Things that aren't limits but are hard-coded thresholds:

  • frequency of chunk splits (which is some kind of function of chunk size or number of documents inserted, whichever comes first)
  • frequency of journal commits (which is a function of time or write volume whichever comes first).
  • cursor timeouts, batch sizes, etc.
Comment by Kyle Banker [ 16/Dec/11 ]

I believe that this would be great for the reference section.

Generated at Thu Feb 08 07:37:54 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.