- Reference >
- MongoDB Server Parameters
MongoDB Server Parameters¶
On this page
Synopsis¶
MongoDB provides a number of configuration options that are accessible via the setParameter command or the --setParameter option.
For additional configuration options, see Configuration File Options and Manual Page for mongod.
Parameters¶
Authentication Parameters¶
- authenticationMechanisms¶
Changed in version 2.6: Added support for the PLAIN and MONGODB-X509 authentication mechanisms.
Changed in version 3.0: Added support for the SCRAM-SHA-1 authentication mechanism.
Available for both mongod and mongos.
Specifies the list of authentication mechanisms the server accepts. Set this to one or more of the following values. If you specify multiple values, use a comma-separated list and no spaces. For descriptions of the authentication mechanisms, see Authentication.
Value Description SCRAM-SHA-1 RFC 5802 standard Salted Challenge Response Authentication Mechanism using the SHA-1 hash function. MONGODB-CR MongoDB challenge/response authentication. MONGODB-X509 MongoDB TLS/SSL certificate authentication. GSSAPI (Kerberos) External authentication using Kerberos. This mechanism is available only in MongoDB Enterprise. PLAIN (LDAP SASL) External authentication using LDAP. PLAIN transmits passwords in plain text. This mechanism is available only in MongoDB Enterprise. For example, to specify PLAIN as the authentication mechanism, use the following command:
mongod --setParameter authenticationMechanisms=PLAIN --auth
- clusterAuthMode¶
New in version 2.6.
Available for both mongod and mongos.
Set the clusterAuthMode to either sendX509 or x509. Useful during rolling upgrade to use x509 for membership authentication to minimize downtime.
Changed in version 3.0: Most MongoDB distributions now include support for TLS/SSL. See Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients for more information about TLS/SSL and MongoDB.
db.getSiblingDB('admin').runCommand( { setParameter: 1, clusterAuthMode: "sendX509" } )
- enableLocalhostAuthBypass¶
New in version 2.4.
Available for both mongod and mongos.
Specify 0 or false to disable localhost authentication bypass. Enabled by default.
enableLocalhostAuthBypass is not available using setParameter database command. Use the setParameter option in the configuration file or the --setParameter option on the command line.
See Localhost Exception for more information.
- saslauthdPath¶
Note
Available only in MongoDB Enterprise (except MongoDB Enterprise for Windows).
Available for both mongod and mongos.
Specify the path to the Unix Domain Socket of the saslauthd instance to use for proxy authentication.
- saslHostName¶
New in version 2.4.
Available for both mongod and mongos.
saslHostName overrides MongoDB’s default hostname detection for the purpose of configuring SASL and Kerberos authentication.
saslHostName does not affect the hostname of the mongod or mongos instance for any purpose beyond the configuration of SASL and Kerberos.
You can only set saslHostName during start-up, and cannot change this setting using the setParameter database command.
Note
saslHostName supports Kerberos authentication and is only included in MongoDB Enterprise. For Linux systems, see Configure MongoDB with Kerberos Authentication on Linux for more information.
- saslServiceName¶
New in version 2.4.6.
Available for both mongod and mongos.
Allows users to override the default Kerberos service name component of the Kerberos principal name, on a per-instance basis. If unspecified, the default value is mongodb.
MongoDB only permits setting saslServiceName at startup. The setParameter command can not change this setting.
saslServiceName is only available in MongoDB Enterprise.
Important
Ensure that your driver supports alternate service names.
- scramIterationCount¶
New in version 3.0.0.
Default: 10000
Available for both mongod and mongos.
Changes the number of hashing iterations used for all new stored passwords. More iterations increase the amount of time required for clients to authenticate to MongoDB, but makes passwords less susceptible to brute-force attempts. The default value is ideal for most common use cases and requirements. If you modify this value, it does not change the number of iterations for existing passwords.
You can set scramIterationCount when starting MongoDB or on running mongod instances.
- sslMode¶
New in version 2.6.
Available for both mongod and mongos.
Set the net.ssl.mode to either preferSSL or requireSSL. Useful during rolling upgrade to TLS/SSL to minimize downtime.
Changed in version 3.0: Most MongoDB distributions now include support for TLS/SSL. See Configure mongod and mongos for TLS/SSL and TLS/SSL Configuration for Clients for more information about TLS/SSL and MongoDB.
db.getSiblingDB('admin').runCommand( { setParameter: 1, sslMode: "preferSSL" } )
- supportCompatibilityFormPrivilegeDocuments¶
Changed in version 3.0: Removed in MongoDB 3.0
Deprecated since version 2.6: supportCompatibilityFormPrivilegeDocuments has no effect in 2.6 and will be removed in 3.0.
New in version 2.4.
- userCacheInvalidationIntervalSecs¶
Default: 30.
Available for mongos only.
On a mongos instance, specifies the interval (in seconds) at which the mongos instance checks to determine whether the in-memory cache of user objects has stale data, and if so, clears the cache. If there are no changes to user objects, mongos will not clear the cache.
This parameter has a minimum value of 1 second and a maximum value of 86400 seconds (24 hours).
Changed in version 3.0: Default value has changed to 30 seconds, and the minimum value allowed has changed to 1 second. mongos only clears the user cache if there are changes.
General Parameters¶
- connPoolMaxShardedConnsPerHost¶
New in version 2.6.
Default: 200
Available for both mongod and mongos.
Set the maximum size of the connection pools for communication to the shards. The size of a pool does not prevent the creation of additional connections, but does prevent the connection pools from retaining connections above this limit.
Increase the connPoolMaxShardedConnsPerHost value only if the number of connections in a connection pool has a high level of churn or if the total number of created connections increase.
You can only set connPoolMaxShardedConnsPerHost during startup in the config file or on the command line, as follows to increase the size of the connection pool:
mongos --setParameter connPoolMaxShardedConnsPerHost=250
- connPoolMaxConnsPerHost¶
New in version 2.6.
Default: 200
Available for both mongod and mongos.
Set the maximum size of the connection pools for outgoing connections to other mongod instances. The size of a pool does not prevent the creation of additional connections, but does prevent a connection pool from retaining connections in excess of the value of connPoolMaxConnsPerHost.
Only adjust this setting if your driver does not pool connections and you’re using authentication in the context of a sharded cluster.
You can only set connPoolMaxConnsPerHost during startup in the config file or on the command line, as in the following example:
mongod --setParameter connPoolMaxConnsPerHost=250
- cursorTimeoutMillis¶
New in version 3.0.2.
Default: 600000 (i.e. 10 minutes)
Available for both mongod and mongos.
Sets the expiration threshold in milliseconds for idle cursors before MongoDB removes them; i.e. MongoDB removes cursors that have been idle for the specified cursorTimeoutMillis.
For example, the following sets the cursorTimeoutMillis to 300000 milliseconds (i.e. 5 minutes).
mongod --setParameter cursorTimeoutMillis=300000
Or, if using the setParameter command within the mongo shell:
db.getSiblingDB('admin').runCommand( { setParameter: 1, cursorTimeoutMillis: 300000 } )
- enableTestCommands¶
New in version 2.4.
Available for both mongod and mongos.
enableTestCommands enables a set of internal commands useful for internal testing operations. enableTestCommands is only available at startup and you cannot use setParameter to modify this parameter. Consider the following mongod invocation, which sets enableTestCommands:
mongod --setParameter enableTestCommands=1
enableTestCommands provides access to the following internal commands:
- failIndexKeyTooLong¶
New in version 2.6.
Available for mongod only.
In MongoDB 2.6, if you attempt to insert or update a document so that the value of an indexed field is longer than the Index Key Length Limit, the operation will fail and return an error to the client. In previous versions of MongoDB, these operations would successfully insert or modify a document but the index or indexes would not include references to the document.
To avoid this issue, consider using hashed indexes or indexing a computed value. If you have an existing data set and want to disable this behavior so you can upgrade and then gradually resolve these indexing issues, you can use failIndexKeyTooLong to disable this behavior.
failIndexKeyTooLong defaults to true. When false, a 2.6 mongod instance will provide the 2.4 behavior.
Issue the following command to disable the index key length validation: for a running:program:mongod instance:
db.getSiblingDB('admin').runCommand( { setParameter: 1, failIndexKeyTooLong: false } )
You can also set failIndexKeyTooLong at startup time with the following option:
mongod --setParameter failIndexKeyTooLong=false
- newCollectionsUsePowerOf2Sizes¶
Deprecated since version 3.0.0: MongoDB deprecates the newCollectionsUsePowerOf2Sizes parameter such that you cannot set the newCollectionsUsePowerOf2Sizes to false and newCollectionsUsePowerOf2Sizes set to true is a no-op. To disable the power of 2 allocation for a collection, use the collMod command with the noPadding flag or the db.createCollection() method with the noPadding option.
Default: true.
Available for mongod only.
Available for the MMAPv1 storage engine only.
- notablescan¶
Available for mongod only.
Specify whether all queries must use indexes. If 1, MongoDB will not execute queries that require a table scan and will return an error.
Consider the following example which sets notablescan to 1 or true:
db.getSiblingDB("admin").runCommand( { setParameter: 1, notablescan: 1 } )
Setting notablescan to 1 can be useful for testing application queries, for example, to identify queries that scan an entire collection and cannot use an index.
To detect unindexed queries without notablescan, consider reading the Evaluate Performance of Current Operations and Optimize Query Performance sections and using the logLevel parameter, mongostat and profiling.
Don’t run production mongod instances with notablescan because preventing table scans can potentially affect queries in all databases, including administrative queries.
- textSearchEnabled¶
Deprecated since version 2.6: MongoDB enables the text search feature by default. Manual enabling of this feature is unnecessary.
Available for both mongod and mongos.
Enables the text search feature. When manually enabling, you must enable on each and every mongod for replica sets.
- ttlMonitorEnabled¶
New in version 2.4.6.
Available for mongod only.
To support TTL Indexes, mongod instances have a background thread that is responsible for deleting documents from collections with TTL indexes.
To disable this worker thread for a mongod, set ttlMonitorEnabled to false, as in the following operations:
db.getSiblingDB('admin').runCommand( { setParameter: 1, ttlMonitorEnabled: false } )
Alternately, you may disable the thread at startup time by starting the mongod instance with the following option:
mongod --setParameter ttlMonitorEnabled=false
- disableJavaScriptJIT¶
New in version 3.2.
Available for mongod only.
The MongoDB JavaScript engine uses SpiderMonkey, which implements Just-in-Time (JIT) compilation for improved performance when running scripts.
To disable the JIT, set disableJavaScriptJIT to true, as in the following example:
db.getSiblingDB('admin').runCommand( { setParameter: 1, disableJavaScriptJIT: true } )
Be aware that group and $where will reuse existing JavaScript interpreter contexts, so changes to disableJavaScriptJIT may not take effect immediately for these operations.
Alternately, you may disable the JIT at startup time by starting the mongod instance with the following option:
mongod --setParameter disableJavaScriptJIT=true
Logging Parameters¶
- logLevel¶
Available for both mongod and mongos.
Specify an integer between 0 and 5 signifying the verbosity of the logging, where 5 is the most verbose.
Consider the following example which sets the logLevel to 2:
use admin db.runCommand( { setParameter: 1, logLevel: 2 } )
The default logLevel is 0.
See also
- logComponentVerbosity¶
New in version 3.0.0.
Available for both mongod and mongos.
Sets the verbosity levels of various components for log messages. The verbosity level determines the amount of Informational and Debug messages MongoDB outputs.
The verbosity level can range from 0 to 5:
- 0 is the MongoDB’s default log verbosity level, to include Informational messages.
- 1 to 5 increases the verbosity level to include Debug messages.
For a component, you can also specify -1 to inherit the parent’s verbosity level.
To specify the verbosity level, use a document similar to the following:
{ verbosity: <int>, <component1>: { verbosity: <int> }, <component2>: { verbosity: <int>, <component3>: { verbosity: <int> } }, ... }For the components, you can specify just the <component>: <int> in the document, unless you are setting both the parent verbosity level and that of the child component(s) as well:
{ verbosity: <int>, <component1>: <int> , <component2>: { verbosity: <int>, <component3>: <int> } ... }The top-level verbosity field corresponds to systemLog.verbosity which sets the default level for all components. The default value of systemLog.verbosity is 0.
The components correspond to the following settings:
- accessControl
- command
- control
- geo
- index
- network
- query
- replication
- sharding
- storage
- storage.journal
- write
Unless explicitly set, the component has the verbosity level of its parent. For example, storage is the parent of storage.journal. That is, if you specify a storage verbosity level, this level also applies to storage.journal components unless you specify the verbosity level for storage.journal.
For example, the following sets the default verbosity level to 1, the query to 2, the storage to 2, and the storage.journal to 1.
use admin db.runCommand( { setParameter: 1, logComponentVerbosity: { verbosity: 1, query: { verbosity: 2 }, storage: { verbosity: 2, journal: { verbosity: 1 } } } } )
You can also set parameter logComponentVerbosity at startup time, passing the verbosity level document as a string.
mongo shell also provides the db.setLogLevel() to set the log level for a single component. For various ways to set the log verbosity level, see Configure Log Verbosity Levels.
- logUserIds¶
New in version 2.4.
Available for both mongod and mongos.
Specify 1 to enable logging of userids.
Disabled by default.
- quiet¶
Available for both mongod and mongos.
Sets quiet logging mode. If 1, mongod will go into a quiet logging mode which will not log the following events/activities:
- connection events;
- the drop command, the dropIndexes command, the diagLogging command, the validate command, and the clean command; and
- replication synchronization activities.
Consider the following example which sets the quiet to 1:
db = db.getSiblingDB("admin") db.runCommand( { setParameter: 1, quiet: 1 } )
See also
- traceExceptions¶
Available for both mongod and mongos.
Configures mongod to log full source code stack traces for every database and socket C++ exception, for use with debugging. If true, mongod will log full stack traces.
Consider the following example which sets the traceExceptions to true:
db.getSiblingDB("admin").runCommand( { setParameter: 1, traceExceptions: true } )
See also
Diagnostic Parameters¶
To support the diagnostic data capture, MongoDB introduces the following parameters:
Note
The default values for the diagnostic data capture interval and the maximum sizes are chosen to provide useful data to MongoDB engineers with minimal impact on performance and storage size. Typically, these values will only need modifications as requested by MongoDB engineers for specific diagnostic purposes.
Diagnostic data files are stored in the diagnostic.data directory under the mongod instance’s --dbpath or storage.dbPath.
- diagnosticDataCollectionEnabled¶
New in version 3.2.
Type: boolean
Default: true
Available for mongod only.
Determines whether to enable the collecting and logging of data for diagnostic purposes. Diagnostic logging is enabled by default.
For example, the following disables the diagnostic collection:
mongod --setParameter diagnosticDataCollectionEnabled=false
- diagnosticDataCollectionDirectorySizeMB¶
New in version 3.2.
Type: integer
Default: 100
Available for mongod only.
Specifies the maximum size, in megabytes, of the diagnostic.data directory . If directory size exceeds this number, the oldest diagnostic files in the directory are automatically deleted based on the timestamp in the file name.
For example, the following sets the maximum size of the directory to 200 megabytes:
mongod --setParameter diagnosticDataCollectionDirectorySizeMB=200
The minimum value for diagnosticDataCollectionDirectorySizeMB is 10 megabytes. diagnosticDataCollectionDirectorySizeMB must be greater than maximum diagnostic file size diagnosticDataCollectionFileSizeMB.
- diagnosticDataCollectionFileSizeMB¶
New in version 3.2.
Type: integer
Default: 10
Available for mongod only.
Specifies the maximum size, in megabytes, of each diagnostic file. If the file exceeds the maximum file size, MongoDB creates a new file.
For example, the following sets the maximum size of each diagnostic file to 20 megabytes:
mongod --setParameter diagnosticDataCollectionFileSizeMB=20
The minimum value for diagnosticDataCollectionFileSizeMB is 1 megabyte.
- diagnosticDataCollectionPeriodMillis¶
New in version 3.2.
Type: integer
Default: 1000
Available for mongod only.
Specifies the interval, in milliseconds, at which to collect diagnostic data.
For example, the following sets the interval to 5000 milliseconds or 5 seconds:
mongod --setParameter diagnosticDataCollectionPeriodMillis=5000
The minimum value for diagnosticDataCollectionPeriodMillis is 100 milliseconds.
Replication Parameters¶
- replApplyBatchSize¶
Available for mongod only.
Specify the number of oplog entries to apply as a single batch. replApplyBatchSize must be an integer between 1 and 1024. The default value is 1. This option only applies to master/slave configurations and is valid only on a mongod started with the --slave command line option.
Batch sizes must be 1 for members with slavedelay configured.
- replIndexPrefetch¶
Available for mongod only.
Use replIndexPrefetch in conjunction with replSetName when configuring a replica set. The default value is all and available options are:
- none
- all
- _id_only
By default secondary members of a replica set will load all indexes related to an operation into memory before applying operations from the oplog. You can modify this behavior so that the secondaries will only load the _id index. Specify _id_only or none to prevent the mongod from loading any index into memory.
- replWriterThreadCount¶
New in version 3.2.
Type: integer
Default: 16
Available for mongod only.
Number of threads to use to apply replicated operations in parallel. Values can range from 1 to 256 inclusive. You can only set replWriterThreadCount at startup and cannot change this setting with the setParameter command.
Sharding Parameters¶
Storage Parameters¶
- journalCommitInterval¶
Available for mongod only.
Specify an integer between 1 and 500 signifying the number of milliseconds (ms) between journal commits.
Consider the following example which sets the journalCommitInterval to 200 ms:
db.getSiblingDB("admin").runCommand( { setParameter: 1, journalCommitInterval: 200 } )
See also
- syncdelay¶
Available for mongod only.
Specify the interval in seconds between fsync operations where mongod flushes its working memory to disk. By default, mongod flushes memory to disk every 60 seconds. In almost every situation you should not set this value and use the default setting.
Consider the following example which sets the syncdelay to 60 seconds:
db.getSiblingDB("admin").runCommand( { setParameter: 1, syncdelay: 60 } )
See also
syncPeriodSecs and journalCommitInterval.
WiredTiger Parameters¶
- wiredTigerConcurrentReadTransactions¶
New in version 3.0.0.
Available for mongod only.
Available for the WiredTiger storage engine only.
Specify the maximum number of concurrent read transactions allowed into the WiredTiger storage engine.
db.adminCommand( { setParameter: 1, wiredTigerConcurrentReadTransactions: <num> } )
See also
- wiredTigerConcurrentWriteTransactions¶
New in version 3.0.0.
Available for mongod only.
Available for the WiredTiger storage engine only.
Specify the maximum number of concurrent write transactions allowed into the WiredTiger storage engine.
db.adminCommand( { setParameter: 1, wiredTigerConcurrentWriteTransactions: <num> } )
See also
- wiredTigerEngineRuntimeConfig¶
New in version 3.0.0.
Available for mongod only.
Specify wiredTiger storage engine configuration options for a running mongod instance. You can only set this parameter using the setParameter command and not using the command line or configuration file option.
Consider the following operation prototype:
db.adminCommand({ "setParameter": 1, "wiredTigerEngineRuntimeConfig": "<option>=<setting>,<option>=<setting>" })
See the WiredTiger documentation for all available WiredTiger configuration options.
Auditing Parameters¶
- auditAuthorizationSuccess¶
New in version 2.6.5.
Default: false
Note
Available only in MongoDB Enterprise.
Available for both mongod and mongos.
Enables the auditing of authorization successes for the authCheck action.
When auditAuthorizationSuccess is false, the audit system only logs the authorization failures for authCheck.
To enable the audit of authorization successes, issue the following command:
db.adminCommand( { setParameter: 1, auditAuthorizationSuccess: true } )
Enabling auditAuthorizationSuccess degrades performance more than logging only the authorization failures.
Thank you for your feedback!
We're sorry! You can Report a Problem to help us improve this page.