View a markdown version of this page

长时间运行的查询 - Amazon DocumentDB
概述对集群的影响监控和检测补救策略
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

长时间运行的查询

概述

长时间运行的查询可能会导致整个集群的性能问题。这些查询可能会干扰 Amazon DocumentDB 的多版本并发控制 (MVCC) 垃圾收集流程，从而导致旧版本文档积累并降低整个集群的性能。Amazon DocumentDB 实施了 2 小时的服务器端超时作为一种安全机制，以无限期限制失控的查询消耗资源。

什么是长时间运行的查询：

  • 长时间执行的查询（通常大于 30 分钟）

  • 打开保持活动状态数小时的游标（如果光标处于活动状态，则不适用 2 小时的超时时间）

对集群的影响

长时间运行的查询可能会干扰垃圾收集进程

  • 旧版本累积：垃圾收集器无法回收旧文档版本

  • 集合和索引膨胀：集合和索引条目会随着时间的推移而累积，膨胀会增加，这可能会导致更多的存储成本。

  • CPU 和内存压力：由于处理越来越多的旧文档版本、索引条目和事务 IDs处理效率低下，CPU 和内存压力增加。

长时间运行的查询 → 阻止 GC → 存储增长 → CPU 和内存压力 → 更多长查询

监控和检测

1。要查找长时间运行的查询，请使用 currentOp 命令。


// To find a query running for more than 30 mins
db.adminCommand({
    aggregate: 1,
    pipeline: [
        {$currentOp: {}},
        {$match: 
            {$or: 
                [{secs_running: {$gt: 1800}},
                 {WaitState: {$exists: true}}]}}],
    cursor: {}
});

2。查找活动时间超过 30 分钟的光标


// To find cursor which is running more than 30 mins
db.adminCommand({
    "currentOp": true,
    "active": true,
    "$all": true
}).inprog.filter(function(op) {
    return op.desc == "Cursor" && 
           op.secs_running > 1800 && 
           op.active == true;
}).sort((a, b) => b.microsecs_running - a.microsecs_running)

3。通过监控垃圾收集器的进度 CloudWatch

LongestRunningGCProcess— 最长活动垃圾收集过程的持续时间（以秒为单位）。每分钟更新一次，仅跟踪活动操作，不包括在一分钟时段内完成的进程。

AvailableMVCCIds-一个计数器，显示在达到零之前剩余的可用写入操作数。当此计数器达到零时，您的集群将进入只读模式，直到 IDs 被回收和回收。计数器会随着每次写入操作而减少，并随着垃圾收集回收旧的 M IDs VCC 而增加。

注意

较低的 MVCC IDs 和较长的垃圾收集持续时间并不完全归因于长时间运行的查询。资源受限的实例上的写入密集型工作负载也可能导致 MVCC ID 可用性降低，垃圾收集周期延长。

补救策略

  • 在应用程序中实现查询超时

  • 不要让光标存活时间更长

  • 优化查询以提高性能。

  • 更喜欢批量写入操作