如何确定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

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

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

如果您想确定增加的getmore计数的来源，您可以看到这些记录在logLevel 1或更高。

logLevel parameter可以在启动时设置或在运行时调整。随着额外的细节，日志会很快变大，所以我建议在MMS中指示的一个高峰期内，在短时间内增加样本getmores。

要在logLevel shell中使用增加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”之后（以及查询之前）的文本表示namespace（即“database.collection”）。

来自复制或任何其他应用程序tailing the oplog的getmore查询（例如MMS备份或MongoDB连接器）将始终位于local.oplog.rs命名空间。

Answer 2

里程可能因此而有所不同，但我希望大getmore次计数仅仅是获取结果的数量的指标。根据定义，它是一个游标批处理请求，我将看到的最直接的关联是期望它是查询操作数的倍数。是的，这也包括复制，因为查询将由辅助代码发布到oplog。

这是有道理的，因为每个查询都将设置一个游标来返回结果，该批次将被取出，当用尽时，新的op将会发出。现在可以公平地说，对于大部分查询来说，每个请求使用最少数量的 getmore 操作是最佳的，但这可能不是最实用的方法。如上所述，YMMV。

因此，我认为＆＃34; Peace of Mind＆＃34; 的一个相关性将是查看正在执行的查询，返回的数据类型以及结果数量。获取该信息是与Database Profiler一起玩，然后玩弄结果的问题。

oplog中的数据也应该与复制操作中出现峰值的高计数时间相关联，因此您应该能够看到它的影响。