修改mongodb最大查询数_关于MongoDB最大连接数的查看与修改

在Linux平台下，无论是64位或者32位的MongoDB默认最大连接数都是819，WIN平台不知道，估计也没有人在 WIN平台下使用MongoDB做生产环境

[root@DELL113 mongodb-linux-i686-2.4.1]# mongo admin -u root -p password

MongoDB shell version: 2.4.1

connecting to: 192.168.6.42/admin

> db.serverStatus().connections

{ "current" : 1, "available" : 818, "totalCreated" : NumberLong(1) }

途中available显示818少了一个，表示空闲的。current表示已经占用了的连接数，两数一加就等于819，如果我现在在连接一个，那么available就是817，current就是2

[root@linuxidc mongodb-linux-i686-2.4.1]#./bin/mongo 192.168.6.42MongoDB shell version: 2.4.1

connecting to: 192.168.6.42/test

> db.serverStatus().connections

{ "current" : 1, "available" : 818, "totalCreated" : NumberLong(1) }

> db.serverStatus().connections

{ "current" : 2, "available" : 817, "totalCreated" : NumberLong(2) }

819个连接数对于一般的站点我认为已经够用，并且都是现连现取现断。但这个连接数也可以修改，只要在启动的时候加入--maxConns即可

服务器启动

[root@lee mongodb-linux-x86_64-2.4.1]#./bin/mongod --dbpath=/root/db --maxConns=2000Wed Apr 3 11:06:21.905 [initandlisten] MongoDB starting : pid=2812 port=27017 dbpath=/root/db 64-bit host=lee

Wed Apr 3 11:06:21.957 [initandlisten] db version v2.4.1

Wed Apr 3 11:06:21.957 [initandlisten] git version: 1560959e9ce11a693be8b4d0d160d633eee75110

Wed Apr 3 11:06:21.957 [initandlisten] build info: Linux ip-10-2-29-40 2.6.21.7-2.ec2.v1.2.fc8xen #1 SMP Fri Nov 20 17:48:28 EST 2009 x86_64 BOOST_LIB_VERSION=1_49Wed Apr 3 11:06:21.957 [initandlisten] allocator: tcmalloc

Wed Apr 3 11:06:21.957 [initandlisten] options: { dbpath: "/root/db", maxConns: 2000 }

Wed Apr 3 11:06:21.982 [initandlisten] journal dir=/root/db/journal

Wed Apr 3 11:06:21.982 [initandlisten] recover : no journal files present, no recovery needed

Wed Apr 3 11:06:22.297 [initandlisten] preallocateIsFaster=true 2.62

Wed Apr 3 11:06:22.717 [initandlisten] --maxConns too high, can only handle 819

Wed Apr 3 11:06:22.724 [initandlisten] waiting for connections on port 27017

Wed Apr 3 11:06:22.725 [websvr] admin web console waiting for connections on port 28017

Wed Apr 3 11:06:25.126 [initandlisten] connection accepted from 192.168.4.86:53917 #1 (1 connection now open)

查询最大连接数

[root@linuxidc mongodb-linux-i686-2.4.1]#./bin/mongo 192.168.6.42MongoDB shell version: 2.4.1

connecting to: 192.168.6.42/test

> db.serverStatus().connections

{ "current" : 1, "available" : 818, "totalCreated" : NumberLong(1) }

>

发现还是819？其实是Linux默认进程能打开最大文件数有关，可以通过ulimit 解决

[root@lee mongodb-linux-x86_64-2.4.1]#ulimit -n 2500[root@lee mongodb-linux-x86_64-2.4.1]#./bin/mongod --dbpath=/root/db --maxConns=2000Wed Apr 3 11:11:07.013 [initandlisten] MongoDB starting : pid=2930 port=27017 dbpath=/root/db 64-bit host=lee

Wed Apr 3 11:11:07.013 [initandlisten] db version v2.4.1

Wed Apr 3 11:11:07.013 [initandlisten] git version: 1560959e9ce11a693be8b4d0d160d633eee75110

Wed Apr 3 11:11:07.013 [initandlisten] build info: Linux ip-10-2-29-40 2.6.21.7-2.ec2.v1.2.fc8xen #1 SMP Fri Nov 20 17:48:28 EST 2009 x86_64 BOOST_LIB_VERSION=1_49Wed Apr 3 11:11:07.013 [initandlisten] allocator: tcmalloc

Wed Apr 3 11:11:07.013 [initandlisten] options: { dbpath: "/root/db", maxConns: 2000 }

Wed Apr 3 11:11:07.031 [initandlisten] journal dir=/root/db/journal

Wed Apr 3 11:11:07.031 [initandlisten] recover : no journal files present, no recovery needed

Wed Apr 3 11:11:07.170 [initandlisten] waiting for connections on port 27017

Wed Apr 3 11:11:07.171 [websvr] admin web console waiting for connections on port 28017

Wed Apr 3 11:11:10.076 [initandlisten] connection accepted from 192.168.4.86:53161 #1 (1 connection now open)

再查看最大连接数，搞定

[root@linuxidc mongodb-linux-i686-2.4.1]#./bin/mongo 192.168.6.42MongoDB shell version: 2.4.1

connecting to: 192.168.6.42/test

> db.serverStatus().connections

{ "current" : 1, "available" : 1999, "totalCreated" : NumberLong(1) }

>

关于ulimit的更多知识大家可以去网上检索检索

客户端程序通常是通过DRIVER来链接，由于每次建立链接的成本都挺高，因此都用链接池来实现，SPRING DATA MONGODB中是如下配置

mongo.dbname=cms

#线程池的大小mongo.connectionsPerHost=100

#这个*mongo.connectionsPerHost则是如果链接数大于100的等待xttk数mongo.threadsAllowedToBlockForConnectionMultiplier=4

#等待线程的等待时间mongo.maxWaitTime=1500

mongo.socketTimeout=1500

mongo.connectTimeout=1000

mongo.autoConnectRetry=true

mongo.socketKeepAlive=true

mongo.slaveOk=true

autoConnectRetry simply means the driver will automatically attempt to reconnect to the server(s) after unexpected disconnects. In production environments you usually want this set to true.

connectionsPerHost are the amount of physical connections a single Mongo instance (it's singleton so you usually have one per application) can establish to a mongod/mongos process. At time of writing the java driver will establish this amount of connections eventually even if the actual query throughput is low (in order words you will see the "conn" statistic in mongostat rise until it hits this number per app server).

There is no need to set this higher than 100 in most cases but this setting is one of those "test it and see" things. Do note that you will have to make sure you set this low enough so that the total amount of connections to your server do not exceed

db.serverStatus().connections.available

In production we currently have this at 40.

connectTimeout. As the name suggest number of milliseconds the driver will wait before a connection attempt is aborted. Set timeout to something long (15-30 seconds) unless there's a realistic, expected chance this will be in the way of otherwise succesful connection attempts. Normally if a connection attempt takes longer than a couple of seconds your network infrastructure isn't capable of high throughput.

maxWaitTime. Number of ms a thread will wait for a connection to become available on the connection pool, and raises an exception if this does not happen in time. Keep default.

socketTimeout. Standard socket timeout value. Set to 60 seconds (60000).

threadsAllowedToBlockForConnectionMultiplier. Multiplier for connectionsPerHost that denotes the number of threads that are allowed to wait for connections to become available if the pool is currently exhausted. This is the setting that will cause the "com.mongodb.DBPortPool$SemaphoresOut: Out of semaphores to get db connection" exception. It will throw this exception once this thread queue exceeds the threadsAllowedToBlockForConnectionMultiplier value. For example, if the connectionsPerHost is 10 and this value is 5 up to 50 threads can block before the aforementioned exception is thrown.

If you expect big peaks in throughput that could cause large queues temporarily increase this value. We have it at 1500 at the moment for exactly that reason. If your query load consistently outpaces the server you should just improve your hardware/scaling situation accordingly.

readPreference. (UPDATED, 2.8+) Used to determine the default read preference and replaces "slaveOk". Set up a ReadPreference through one of the class factory method. A full description of the most common settings can be found at the end of this post

w. (UPDATED, 2.6+) This value determines the "safety" of the write. When this value is -1 the write will not report any errors regardless of network or database errors. WriteConcern.NONE is the appropriate predefined WriteConcern for this. If w is 0 then network errors will make the write fail but mongo errors will not. This is typically referred to as "fire and forget" writes and should be used when performance is more important than consistency and durability. Use WriteConcern.NORMAL for this mode.

If you set w to 1 or higher the write is considered safe. Safe writes perform the write and follow it up by a request to the server to make sure the write succeeded or retrieve an error value if it did not (in other words, it sends a getLastError() command after you write). Note that until this getLastError() command is completed the connection is reserved. As a result of that and the additional command the throughput will be signficantly lower than writes with w <= 0. With a w value of exactly 1 MongoDB guarantees the write succeeded (or verifiably failed) on the instance you sent the write to.

In the case of replica sets you can use higher values for w whcih tell MongoDB to send the write to at least "w" members of the replica set before returning (or more accurately, wait for the replication of your write to "w" members). You can also set w to the string "majority" which tells MongoDB to perform the write to the majority of replica set members (WriteConcern.MAJORITY). Typicall you should set this to 1 unless you need raw performance (-1 or 0) or replicated writes (>1). Values higher than 1 have a considerable impact on write throughput.

fsync. Durability option that forces mongo to flush to disk after each write when enabled. I've never had any durability issues related to a write backlog so we have this on false (the default) in production.

j *(NEW 2.7+)*. Boolean that when set to true forces MongoDB to wait for a successful journaling group commit before returning. If you have journaling enabled you can enable this for additional durability. Refer to http://www.mongodb.org/display/DOCS/Journaling to see what journaling gets you (and thus why you might want to enable this flag).

ReadPreference The ReadPreference class allows you to configure to what mongod instances queries are routed if you are working with replica sets. The following options are available :

ReadPreference.primary() : All reads go to the repset primary member only. Use this if you require all queries to return consistent (the most recently written) data. This is the default.

ReadPreference.primaryPreferred() : All reads go to the repset primary member if possible but may query secondary members if the primary node is not available. As such if the primary becomes unavailable reads become eventually consistent, but only if the primary is unavailable.

ReadPreference.secondary() : All reads go to secondary repset members and the primary member is used for writes only. Use this only if you can live with eventually consistent reads. Additional repset members can be used to scale up read performance although there are limits to the amount of (voting) members a repset can have.

ReadPreference.secondaryPreferred() : All reads go to secondary repset members if any of them are available. The primary member is used exclusively for writes unless all secondary members become unavailable. Other than the fallback to the primary member for reads this is the same as ReadPreference.secondary().

ReadPreference.nearest() : Reads go to the nearest repset member available to the database client. Use only if eventually consistent reads are acceptable. The nearest member is the member with the lowest latency between the client and the various repset members. Since busy members will eventually have higher latencies this should also automatically balance read load although in my experience secondary(Preferred) seems to do so better if member latencies are relatively consistent.

Note : All of the above have tag enabled versions of the same method which return TaggableReadPreference instances instead. A full description of replica set tags can be found here :Replica Set Tags

《MongoDB 权威指南》(MongoDB: The Definitive Guide)英文文字版[PDF] http://www.linuxidc.com/Linux/2012-07/66735.htm

MongoDB 的详细介绍：请点这里

MongoDB 的下载地址：请点这里