MongoDB优化之二：常见优化方法2
连接池xml配置：
<!-- mongodb访问实例工程类--> <mongo:mongo host="${mongo.location}" port="${mongo.port}"> <mongo:options connections-per-host="100" threads-allowed-to-block-for-connection-multiplier="10" connect-timeout="10000" max-wait-time="120000" auto-connect-retry="false" socket-keep-alive="false" socket-timeout="0" slave-ok="false" write-number="1" write-timeout="0" write-fsync="true" /> </mongo:mongo> <mongo:db-factory mongo-ref="mongo" dbname="${mongo.dbName}" username="${mongo.username}" password="${mongo.password}" id="mongoDbFactory" /> <bean id="mongoTemplate" class="org.springframework.data.mongodb.core.MongoTemplate"> <constructor-arg name="mongoDbFactory" ref="mongoDbFactory" /> </bean>
各个参数说明：
#对mongo实例来说，每个host允许链接的最大链接数,这些链接空闲时会放入池中,如果链接被耗尽，任何请求链接的操作会被阻塞等待链接可用,推荐配置10
connectionsPerHost=10
#当链接空闲时,空闲线程池中最大链接数
minPoolsSize=5
#此参数跟connectionsPerHost的乘机为一个线程变为可用的最大阻塞数，超过此乘机数之后的所有线程将及时获取一个异常.eg.connectionsPerHost=10 and threadsAllowedToBlockForConnectionMultiplier=5,最多50个线程等级一个链接，推荐配置为5
threadsAllowedToBlockForConnectionMultiplier=5
#一个线程等待链接可用的最大等待毫秒数，0表示不等待，负数表示等待时间不确定，推荐配置120000
maxWaitTime=120000
#链接超时的毫秒数,0表示不超时,此参数只用在新建一个新链接时，推荐配置10,000.
connectTimeout=10000
#此参数表示socket I/O读写超时时间,推荐为不超时，即 0 Socket.setSoTimeout(int)
socketTimeout=0
#该标志用于控制socket保持活动的功能，通过防火墙保持连接活着
socketKeepAlive=false
#true:假如链接不能建立时,驱动将重试相同的server,有最大的重试次数,默认为15次,这样可以避免一些server因为一些阻塞操作零时down而驱动抛出异常,这个对平滑过度到一个新的master,也是很有用的,注意:当集群为复制集时,驱动将在这段时间里,尝试链接到旧的master上,而不会马上链接到新master上
#false 当在进行socket读写时,不会阻止异常抛出,驱动已经有自动重建破坏链接和重试读操作. 推荐配置false
autoConnectRetry=false
#重新打开链接到相同server的最大毫秒数,推荐配置为0，如果 autoConnectRetry=true,表示时间为15s
#com.jd.mongodbclient2.mongo.JDClientMongo.maxAutoConnectRetryTime=false
#表示当没有手动关闭游标时,是否有一个自动释放游标对象的方法,如果你总是很小心的关闭游标,则可以将其设为false 推荐配置true
#com.jd.mongodbclient2.mongo.JDClientMongo.cursorFinalizerEnabled=true
#安全模式
com.jd.mongodbclient2.driver.MongoDBDriver.safe=true
#为true表示读写分离
com.jd.mongodbclient2.driver.MongoDBDriver.slaveOk=false
1. MongoClientOptions中的连接池配置:
配置如下:
connectionPoolSettings = ConnectionPoolSettings.builder()
.minSize(getMinConnectionsPerHost())
.maxSize(getConnectionsPerHost())
.maxWaitQueueSize(getThreadsAllowedToBlockForConnectionMultiplier()
* getConnectionsPerHost())
.maxWaitTime(getMaxWaitTime(), MILLISECONDS)
.maxConnectionIdleTime(getMaxConnectionIdleTime(), MILLISECONDS)
.maxConnectionLifeTime(getMaxConnectionLifeTime(), MILLISECONDS)
.build();
minSize: 线程池空闲时保持的最小连接数, 默认是0.
maxSize: 线程池允许的最大连接数,默认是100.
maxWaitQueueSize: 线程池等待队列的大小, 默认是500.
maxWaitTime: 线程等待连接变为可用的最长时间.默认为2分钟. 值为0意味着它不会等待. 负值意味着它将无限期地等待
maxConnectionIdleTime: 线程池中连接的最大空闲时间, 0标志Udine空闲时间没有限制,超过这个时间会被关闭.
maxConnectionLifeTime: 线程池中连接的最长生存时间. 0表示没有限制. 超过寿命的会被关闭,必要时通过新连接进行替换.
2. MongoClientOptions初始化
mongodb驱动中 MongoClientOptions 使用Buidler模式配置,有关所有属性的默认值,都是在Builder里边配置的.
关于Builder 的配置如下:
public static class Builder {
private String description;
private String applicationName;
//读取偏好, 这里默认的是从主节点读取.
private ReadPreference readPreference = ReadPreference.primary();
//使用服务器默认的写关注?
private WriteConcern writeConcern = WriteConcern.ACKNOWLEDGED;
//使用服务的默认读关注,默认是local
private ReadConcern readConcern = ReadConcern.DEFAULT;
private CodecRegistry codecRegistry = MongoClient.getDefaultCodecRegistry();
private final List<CommandListener> commandListeners = new ArrayList<CommandListener>();
private final List<ClusterListener> clusterListeners = new ArrayList<ClusterListener>();
private final List<ServerListener> serverListeners = new ArrayList<ServerListener>();
private final List<ServerMonitorListener> serverMonitorListeners = new ArrayList<ServerMonitorListener>();
private int minConnectionsPerHost;
private int maxConnectionsPerHost = 100;
private int threadsAllowedToBlockForConnectionMultiplier = 5;
//设置服务器选择超时（以毫秒为单位），它定义驱动程序在抛出异常之前等待服务器选择成功的时间
//值为0表示如果没有可用的服务器，它将立即超时。 负值意味着无限期等待
private int serverSelectionTimeout = 1000 * 30;
//线程等待连接变为可用的最长时间
private int maxWaitTime = 1000 * 60 * 2;
// 线程池中连接的最大空闲时间
private int maxConnectionIdleTime;
private int maxConnectionLifeTime;
//连接超时时间,必须大于0
private int connectTimeout = 1000 * 10;
//socket超时时间
private int socketTimeout = 0;
//socket是否保活
private boolean socketKeepAlive = false;
private boolean sslEnabled = false;
private boolean sslInvalidHostNameAllowed = false;
private boolean alwaysUseMBeans = false;
//设置心跳频率。 这是驱动程序将尝试确定群集中每个服务器的当前状态的频率。 默认值为10,000毫秒
private int heartbeatFrequency = 10000;
//设置最小心跳频率。 如果驱动程序必须经常重新检查服务器的可用性，它将至少在上一次检查后等待很长时间，以避免浪费精力。 默认值为500毫秒。
private int minHeartbeatFrequency = 500;
//设置用于集群心跳的连接的连接超时
private int heartbeatConnectTimeout = 20000;
//设置用于集群心跳的连接的套接字超时
private int heartbeatSocketTimeout = 20000;
//本地阈值
private int localThreshold = 15;
private String requiredReplicaSetName;
private DBDecoderFactory dbDecoderFactory = DefaultDBDecoder.FACTORY;
private DBEncoderFactory dbEncoderFactory = DefaultDBEncoder.FACTORY;
private SocketFactory socketFactory;
private boolean cursorFinalizerEnabled = true;
...}
3. 需要关心的配置
这里就因人而异了, 我这列出比较重要的几个配置,具体的值看业务场景.
3.1 读写相关
这应该是程序最应该关注的配置了,读关注,写关注,读取偏好.
//读取偏好, 首先从从节点读取. private ReadPreference readPreference = ReadPreference.secondaryPreferred(); //写关注为1 ,写入主节点即返回. private WriteConcern writeConcern = WriteConcern.W1; //使用服务的默认读关注,默认是local(决定到某个读取数据时，能读到什么样的数据) private ReadConcern readConcern = ReadConcern.LOCAL;
3.2 线程池配置
//线程池空闲时保持的最小连接数
minConnectionsPerHost=20
//线程池允许的最大连接数
connectionsPerHost=100
//connectionsPerHost* 5 =最大队列数
threadsAllowedToBlockForConnectionMultiplier=5
//线程池中连接的最大空闲时间,5分钟
maxConnectionIdleTime = 5*60*1000
// 线程池中连接的最长生存时间,采用默认值
maxConnectionLifeTime
3.3 连接配置
//设置服务器选择超时（以毫秒为单位），它定义驱动程序在抛出异常之前等待服务器选择成功的时间
//值为0表示如果没有可用的服务器，它将立即超时。 负值意味着无限期等待
private int serverSelectionTimeout = 1000 * 30;
//连接超时时间,必须大于0
private int connectTimeout = 1000 * 5;
//线程等待连接变为可用的最长时间.
maxWaitTime=6000
这里建议 这两个参数: maxWaitTime,connectTimeout,根据公司具体的业务来..
四个方面进行 cpu/io 方面的优化处理：
1.集群架构上进行读写分离。所有查询优先考虑在从库上读取，写操作在主库上执行。避免主库混合读写压力过大，也减少主库上读写记录的锁冲突。
connection string中readPreference 设置成secondarypreferred，C++ 驱动版本升级为3.1.3 mongo-cxx-driver（驱动升级，读写分离才生效） 。
2.热表msg_traces 索引优化
针对该慢查询创建联合索引 {"_id": 1, "account": 1, "app_key": 1, "s_pc": 1}。
3.mongodb 历史数据归档和删除
和开发同事沟通，根据实际业务需求，保留msgs、msg_traces 集合中一年左右的文档。在timestamp 字段上创建TTL索引。设置文档的过期时间为 3153600秒（365*24*3600）。
db.msgs.createIndex( { "timestamp ": 1 }, { expireAfterSeconds: 3153600 },{background: true} )
db.msg_traces.createIndex( { "timestamp ": 1 }, { expireAfterSeconds: 3153600 },{background: true} )
mongodb TTL索引将每隔60秒对过期数据执行一次删除操作。删除操作的持续实际取决于mongod 实例的负载。
4 .journal 日志的 commitIntervalMs 参数调整。
从默认的100ms调大到500ms。
目前通过读写分离和索引优化之后，原来分片1在业务高峰期间的cpu load 值由最高值250降低到5以内，优化效果非常明显。
mongodb 分片集群优化思路总结：
分片集群中出现某个分片负载特别高的情况。（往往是某个分片负载高，如果是多个分片节点负载都高，则需要逐个进行分析）
第一步：
首先通过top、iostat、vmstat、mongostat 等工具了解系统大致并发负载和读写比例，观察系统具体瓶颈所在。
第二步：
如果负载只是集中出现在某一个节点上，则通过 mongotop 工具先分析该mongodb实例的热点表是哪些并记录下来。
第三步：
通过 mlogfilter / mloginfo 工具分析业务高峰期间出现的TOP10 慢查询。
第四步：
定位需要优化的目标表,并进行查询优化。
通常第二步和第三步会出现很多相同的表。因为热点数据表和慢查询表往往存在相同的一些表。这些表就是我们需要优化的目标。
mongodb 分片表的优化大致从以下几方面着手：
1.查看表分片键、数据分布、数据总量、数据占用空间等信息。着重看数据分片键设置是否合理、数据分布是否均匀；
2.mloginfo 工具打印出来的慢查询信息中有每个慢查询的查询条件。确认慢查询表上是否有合适的索引满足查询条件执行。需要结合explain() 分析慢查询的具体执行计划。
3.选取业务高峰阶段的mongodb实例原始日志，搜索慢查询表相关的原始查询语句。记录这些原始查询语句，方便后续与开发同事沟通，看能否从业务场景上进行相应的优化。
4.对于日志、事件、会话信息等日志类型的表，可以按照业务需求，根据事件字段，只保留一定时间内的有效数据。通常这要与开发业务沟通清楚。确认保留时间后，可以利用mongodb TTL索引特性，在特定时间字段上创建索引，设置记录过期时限。
第五步：
架构上做读写分离优化
如果在第三步找出来的 TOP10 慢查询不少是能有效利用索引的简单查询，正常情况下，执行应该很快（200ms之内）。
则需要考虑在架构上做读写分离的优化。因为热点表高并发的读写会让cpu 忙不过来，导致原本正常的查询都出现阻塞。
总之，mongodb 优化关键之处是找出系统瓶颈和问题根源。定位出需要优化的目标表后，简单地加个索引或者做个读写分离，性能问题往往就迎刃而解。
这个和医生看病颇为相似，通过望闻问切和各种医疗检验设备所反馈的数据和报告，再依据丰富的临床经验诊断出病因所在。找出病因后，开什么方子用什么药就是水到渠成的事了。当然，医生看病比给数据库做性能诊断复杂多了，误诊几率也不小。而且，数据库性能优化没找准原因还有不少试错的机会，但是医生试错成本就比较高了。所以当个好医生貌似比做个好DBA更难！
以上插了些题外话。优化上过程中，也需要和开发同事保持有效沟通。当我们理解慢查询产生的业务场景后，有时让开发同事配合做个简单的功能优化，头痛的性能问题也能随之解决。
