如何确定ops导致MongoDB服务器上的getMore操作

Question

我在我的复制集中的主服务器上的mongostat中看到以下内容:

insert  query update delete getmore command flushes mapped  vsize    res faults       locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn   set repl       time
     0    414    388      0    1218     444       0  24.2g  51.4g     3g      0  <redacted>:9.6%          0       0|0     0|0   225k   441k   463 mover  PRI   03:26:30
     0    469    457      0    1352     516       0  24.2g  51.4g     3g      0 <redacted>:10.6%          0       0|0     0|0   258k   498k   463 mover  PRI   03:26:31
     0    478    482      0    1430     548       0  24.2g  51.4g     3g      0 <redacted>:12.0%          0       0|0     0|0   271k   512k   463 mover  PRI   03:26:32

正如您所看到的,getmore计数主导着任何其他形式的操作.这是刚刚开始发生的事情,可以在附加的opcounters图中看到.从我所看到的,这些可能来自副本集操作,但对于我的想法,我想找到一种方法来确认.无论如何我可以确定这些getmore操作的来源吗？

更新:添加了来自MMS的opcounters的新屏幕截图,其中包括图例.

Answer 1

A getmore表示从打开的游标中获取"下一批结果".这可能表示应用程序必须获取多个批次的大型结果集,或者长时间运行的操作(例如复制尾随oplog).

鉴于从1月26日开始有大幅跳跃,我会考虑您是否更改了应用程序或使用中可能与此更改相关的任何内容.也许您开始了一个新的备份例程,或者您的一个常见查询现在有足够的数据需要多个批次.

如果要确定增加getmore计数的来源,可以看到这些记录为logLevel1或更高.

该logLevel参数可以在启动时设置或在运行时调整.随着额外的细节,日志将迅速变大,因此我建议在MMS中指示的一个高峰期期间增加一小段时间来获取getmores.

为了增加logLevel在mongo外壳使用:

db.adminCommand( { setParameter: 1, logLevel: 1 } )

您可以使用以下命令更改回默认值logLevel:

db.adminCommand( { setParameter: 1, logLevel: 0 } )

增加之后logLevel,你应该能够在你的mongod日志中找到"getmore"行,这类似于:

Sun Feb  9 09:31:14.573 [conn8527] getmore local.oplog.rs query: { .. }

"getmore"之后(以及查询之前)的文本表示命名空间(即"database.collection").

在getmore从复制查询或任何其他应用程序拖尾OPLOG(如彩信备份或MongoDB的连接器)将永远是对local.oplog.rs的命名空间.