如何配置 MongoDB Java 驱动程序 MongoOptions 以供生产使用？
我一直在网上搜索为 MongoDB Java 驱动程序配置 MongoOptions 的最佳实践，但除了 API 之外我没有想出太多其他方法。这个搜索是在我遇到“com.mongodb.DBPortPool$SemaphoresOut：Out of semaphores to get db”之后开始的 连接”错误，通过增加连接/乘数我能够解决这个问题。我正在寻找链接或您在生产中配置这些选项的最佳实践。2.4
驱动程序的选项包括： http://api.mongodb.org/java/2.4/com/mongodb/MongoOptions.html< /a>
- autoConnectRetryconnectionsPerHostconnectTimeoutmaxWaitTimesocketTimeoutthreadsAllowedToBlockForConnectionMultiplier
- 选项
- 。
- 新的
- 较
- 驱动程序有
更多选项，我也有兴趣了解这些
I've been searching the web looking for best practices for configuring MongoOptions for the MongoDB Java driver and I haven't come up with much other than the API. This search started after I ran into the "com.mongodb.DBPortPool$SemaphoresOut: Out of semaphores to get db
connection" error and by increasing the connections/multiplier I was able to solve that problem. I'm looking for links to or your best practices in configuring these options for production.
The options for the 2.4 driver include:
http://api.mongodb.org/java/2.4/com/mongodb/MongoOptions.html
- autoConnectRetry
- connectionsPerHost
- connectTimeout
- maxWaitTime
- socketTimeout
- threadsAllowedToBlockForConnectionMultiplier
The newer drivers have more options and I would be interested in hearing about those as well.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
更新至 2.9：
autoConnectRetry 只是意味着驱动程序将在意外断开连接后自动尝试重新连接到服务器。在生产环境中，您通常希望将此设置为 true。
connectionsPerHost 是单个 Mongo 实例（它是单例的，因此通常每个应用程序都有一个）可以与 mongod/mongos 进程建立的物理连接数量。在编写本文时，即使实际查询吞吐量较低，java 驱动程序最终也会建立此数量的连接（换句话说，您将看到 mongostat 中的“conn”统计数据不断上升，直到达到每个应用程序服务器的此数字）。
在大多数情况下，无需将其设置为高于 100，但此设置是“测试并查看”的设置之一。请注意，您必须确保将其设置得足够低，以便与服务器的连接总数不超过
db.serverStatus().connections.available在生产中，我们目前的数量为 40。
连接超时。顾名思义，驱动程序在连接尝试中止之前将等待的毫秒数。将超时设置为较长的时间（15-30 秒），除非存在实际的预期机会，否则这将妨碍成功的连接尝试。通常，如果连接尝试花费的时间超过几秒，您的网络基础设施就无法实现高吞吐量。
最大等待时间。线程将等待连接池中的连接变得可用的毫秒数，如果未及时发生，则会引发异常。保留默认值。
socketTimeout。标准套接字超时值。设置为 60 秒 (60000)。
threadsAllowedToBlockForConnectionMultiplier。 ConnectionsPerHost 的乘数，表示如果池当前已耗尽，则允许等待连接变为可用的线程数。此设置将导致“com.mongodb.DBPortPool$SemaphoresOut：无法获取数据库连接的信号量”异常。一旦该线程队列超过threadsAllowedToBlockForConnectionMultiplier值，它将抛出此异常。例如，如果connectionsPerHost 为10，且该值为5，则在引发上述异常之前最多可阻止 50 个线程。
如果您预计吞吐量的大峰值可能会导致大型队列，请暂时增加此值。正是出于这个原因，我们目前的价格为 1500。如果您的查询负载始终超过服务器，您应该相应地改善硬件/扩展情况。
读取首选项。 （已更新，2.8+） 用于确定默认读取首选项并替换“slaveOk”。通过类工厂方法之一设置 ReadPreference。 可以在本文末尾找到最常见设置的完整说明
w。 （已更新，2.6+） 该值决定写入的“安全性”。当该值为 -1 时，无论网络或数据库错误如何，写入都不会报告任何错误。 WriteConcern.NONE 是为此适当的预定义 WriteConcern。如果 w 为 0，则网络错误将使写入失败，但 mongo 错误不会。这通常称为“即发即忘”写入，当性能比一致性和持久性更重要时应使用。对于此模式，请使用 WriteConcern.NORMAL。
如果将 w 设置为 1 或更高，则写入被认为是安全的。安全写入执行写入，然后向服务器发出请求，以确保写入成功或检索错误值（如果未成功）（换句话说，它会在写入后发送 getLastError() 命令）。请注意，在 getLastError() 命令完成之前，连接将被保留。由于该命令和附加命令，吞吐量将明显低于 w <= 0 的写入。当 aw 值恰好为 1 时，MongoDB 保证在您发送写入的实例上写入成功（或可验证失败）。
对于副本集，您可以使用更高的 w 值，告诉 MongoDB 在返回之前将写入至少发送到副本集的“w”个成员（或更准确地说，等待将写入复制到“ w”成员）。您还可以将 w 设置为字符串“majority”，它告诉 MongoDB 对大多数副本集成员执行写入 (WriteConcern.MAJORITY)。通常，您应该将其设置为 1，除非您需要原始性能（-1 或 0）或复制写入（>1）。大于 1 的值对写入吞吐量有相当大的影响。
fsync。持久性选项在启用后强制 mongo 在每次写入后刷新到磁盘。我从未遇到过与写入积压相关的任何持久性问题，因此我们在生产中将此设置为 false（默认值）。
j *（新 2.7+）*。布尔值，当设置为 true 时，会强制 MongoDB 在返回之前等待成功的日志组提交。如果您启用了日记功能，则可以启用它以提高耐用性。请参阅 http://www.mongodb.org/display/DOCS/Journaling 了解日记可以给您带来什么（这就是为什么您可能想要启用此标志）。
阅读偏好
如果您使用副本集，ReadPreference 类允许您配置路由哪些 mongod 实例查询。可以使用以下选项：
ReadPreference.primary()：所有读取仅转到重复集主要成员。如果您需要所有查询返回一致的（最近写入的）数据，请使用此选项。这是默认值。
ReadPreference.primaryPreferred() ：如果可能，所有读取都会转到重复集主要成员，但如果主要节点不可用，则可能会查询次要成员。因此，如果主数据库变得不可用，读取将最终保持一致，但前提是主数据库不可用。
ReadPreference.secondary()：所有读取都转到辅助重复集成员，而主要成员仅用于写入。仅当您可以接受最终一致的读取时才使用此选项。尽管重复集可以拥有的（投票）成员数量有限，但可以使用其他重复集成员来扩展读取性能。
ReadPreference.secondaryPreferred()：所有读取都会转到辅助重复集成员（如果有可用的辅助重复集成员）。主要成员专门用于写入，除非所有辅助成员都不可用。除了读取的回退到主要成员之外，这与 ReadPreference.secondary() 相同。
ReadPreference.nearest()：读取到数据库客户端可用的最近的重复集成员。仅当最终一致性读取可接受时才使用。最近的成员是客户端和各个重复设置成员之间延迟最低的成员。由于繁忙的成员最终会有更高的延迟，因此应该自动平衡读取负载，尽管根据我的经验，如果成员延迟相对一致，辅助（首选）似乎会做得更好。
注意：以上所有方法都具有相同方法的启用标签版本，它们返回 TaggableReadPreference 实例。副本集标签的完整描述可以在这里找到：副本集标签
Updated to 2.9 :
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.availableIn 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