更新时间：2023-09-26 GMT+08:00
排查DDS实例内存占用较高的问题
使用文档数据库服务时，如果您的内存使用率很高或接近100%，不仅会导致业务请求响应缓慢，也会增大OOM风险，从而影响业务稳定运行。
本章节帮助您分析数据库连接数、慢请求和游标，经过分析优化后，使得数据库的查询相对合理，所有的请求都高效使用了索引，并规范使用游标，从而排查文档数据库服务内存使用率高的问题。如果经确认确实为业务增长导致的内存升高，建议及时进行规格扩容。
排查连接数
分析慢日志
除了降低连接数以外，还需要注意单次请求的内存开销，尽量避免查询语句出现全表扫描、内存排序等。
- 使用慢日志功能，查询当前实例产生的慢日志。
- 分析慢日志，查找内存升高的原因：下面是某个慢请求日志示例，可查看到该请求进行了全表扫描，扫描了1561632个文档，没有通过索引进行查询。
{ "op" : "query", "ns" : "taiyiDatabase.taiyiTables$10002e", "query" : { "find" : "taiyiTables", "filter" : { "filed19" : NumberLong("852605039766") }, "shardVersion" : [ Timestamp(1, 1048673), ObjectId("5da43185267ad9c374a72fd5") ], "chunkId" : "10002e" }, "keysExamined" : 0, "docsExamined" : 1561632, "cursorExhausted" : true, "numYield" : 12335, "locks" : { "Global" : { "acquireCount" : { "r" : NumberLong(24672) } }, "Database" : { "acquireCount" : { "r" : NumberLong(12336) } }, "Collection" : { "acquireCount" : { "r" : NumberLong(12336) } } }, "nreturned" : 0, "responseLength" : 157, "protocol" : "op_command", "millis" : 44480, "planSummary" : "COLLSCAN", "execStats" : { "stage" : "SHARDING_FILTER", [3/1955] "nReturned" : 0, "executionTimeMillisEstimate" : 43701, "works" : 1561634, "advanced" : 0, "needTime" : 1561633, "needYield" : 0, "saveState" : 12335, "restoreState" : 12335, "isEOF" : 1, "invalidates" : 0, "chunkSkips" : 0, "inputStage" : { "stage" : "COLLSCAN", "filter" : { "filed19" : { "$eq" : NumberLong("852605039766") } }, "nReturned" : 0, "executionTimeMillisEstimate" : 43590, "works" : 1561634, "advanced" : 0, "needTime" : 1561633, "needYield" : 0, "saveState" : 12335, "restoreState" : 12335, "isEOF" : 1, "invalidates" : 0, "direction" : "forward", "docsExamined" : 1561632 } }, "ts" : ISODate("2019-10-14T10:49:52.780Z"), "client" : "172.16.36.87", "appName" : "MongoDB Shell", "allUsers" : [ { "user" : "__system", "db" : "local" } ], "user" : "__system@local" }在慢请求日志中，您需要重点关注以下关键字。- 全集合（全表）扫描：COLLSCAN
- 当一个操作请求（如query、update、delete）需要全表扫描时，将大量占用内存资源。在查看慢请求日志时，发现COLLSCAN关键字，很可能是这些查询占用了内存资源。
- 如果该类操作请求较为频繁，建议您对查询的字段建立索引进行优化。
- 全集合（全表）扫描：docsExamined
- 通过查看参数“docsExamined”的值，可以查看一个查询扫描了多少文档。该值越大，请求的内存使用率越高。
- 不合理的索引：IXSCAN、keysExamined
- 大量数据排序：SORT、hasSortStage
当查询请求中包含排序时，参数“hasSortStage”的值为“true”。如果排序无法通过索引实现，将在查询结果中进行排序。由于排序将占用大量内存资源，该场景下，需要通过对经常排序的字段建立索引进行优化。
当您发现SORT关键字时，可以考虑通过索引来优化排序。
索引不是越多越好，过多索引会影响写入和更新的性能。越建议参考ESR原则设计索引，以提高查询效率：
- 精确（Equal）匹配的字段放最前面。
- 排序（Sort）条件放中间。
- 范围（Range）匹配的字段放最后面。
- 全集合（全表）扫描：COLLSCAN
检查游标
游标不规范的使用很容易造成内存升高并且长期不释放的情况，当客户端使用数据库的游标功能时，一定注意主动释放游标（游标的官方说明）。
- 检查游标是否有被设置为不超时，默认情况下数据库会在10分钟后自动释放游标。Java driver给出的游标超时示例代码如下：
MongoCursor<Document> cursor = collection.find(query) .maxTime(10, TimeUnit.MINUTES) .iterator(); - 在使用完游标后客户端是否有主动释放游标。Java driver中的释放示例如下：
cursor.close()
- 如果已有noTimeout（不超时）游标，并且客户端已经无法释放，可重启内存高的实例节点以释放这些游标，但需要注意后续优化业务代码，尽量避免设置不超时游标，并在使用完游标后主动释放。
