文档首页/ 文档数据库服务 DDS/ 最佳实践/ 排查DDS实例内存占用较高的问题
更新时间：2023-09-26 GMT+08:00
查看PDF
分享

排查DDS实例内存占用较高的问题

使用文档数据库服务时，如果您的内存使用率很高或接近100%，不仅会导致业务请求响应缓慢，也会增大OOM风险，从而影响业务稳定运行。

本章节帮助您分析数据库连接数、慢请求和游标，经过分析优化后，使得数据库的查询相对合理，所有的请求都高效使用了索引，并规范使用游标，从而排查文档数据库服务内存使用率高的问题。如果经确认确实为业务增长导致的内存升高，建议及时进行规格扩容。

排查连接数

  1. 查看连接数占比，总的连接数不宜超过当前实例能承受的最大连接数的80%。连接太多会导致内存和多线程上下文的开销增加，影响请求处理延时。
  2. 建议配置连接池，一般情况建议连接池最大不要超过200，具体操作可参考查询及限制连接数。

分析慢日志

除了降低连接数以外，还需要注意单次请求的内存开销，尽量避免查询语句出现全表扫描、内存排序等。

  1. 使用慢日志功能，查询当前实例产生的慢日志。
  2. 分析慢日志，查找内存升高的原因：下面是某个慢请求日志示例，可查看到该请求进行了全表扫描，扫描了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）匹配的字段放最后面。

检查游标

游标不规范的使用很容易造成内存升高并且长期不释放的情况，当客户端使用数据库的游标功能时，一定注意主动释放游标（游标的官方说明）。
  1. 检查游标是否有被设置为不超时，默认情况下数据库会在10分钟后自动释放游标。Java driver给出的游标超时示例代码如下： 
    MongoCursor<Document> cursor = collection.find(query)
                    .maxTime(10, TimeUnit.MINUTES)
                    .iterator();
  2. 在使用完游标后客户端是否有主动释放游标。Java driver中的释放示例如下： 
    cursor.close()
  3. 如果已有noTimeout（不超时）游标，并且客户端已经无法释放，可重启内存高的实例节点以释放这些游标，但需要注意后续优化业务代码，尽量避免设置不超时游标，并在使用完游标后主动释放。

相关文档