如何减少获取 mongodb 模式锁的时间？

Question

我们有一个 mongodb 4.0.10 集群，由 WiredTiger 支持，在生产中，有一个由一个主节点和两个从节点组成的 3 节点副本集。其中一个从站有另一个共同定位的服务，可以广泛地查询从站。在解决协同定位服务中的一些缓慢问题时，我看到了很多令人惊讶的缓慢查询。这个用了 3.3 秒：

  find: "myColl",
  filter: { myField: "myValue" },
  projection: { name: 1 },
  $db: "myDb",
  $clusterTime: { clusterTime: Timestamp(1568198047, 3), signature: { hash: BinData(0, 0000000000000000000000000000000000000000), keyId: 0 } },
  lsid: { id: UUID("2ed823aa-e6af-4898-a4c1-c039d28a32ab") },
  $readPreference: { mode: "secondary" } }
  planSummary: IXSCAN { myField: 1 } keysExamined:0 docsExamined:0 cursorExhausted:1 numYields:0 nreturned:0 reslen:232
  locks:{ Global: { acquireCount: { r: 1 } },
          Database: { acquireCount: { r: 1 } },
          Collection: { acquireCount: { r: 1 } } }
  storage:{ data: { bytesRead: 355, timeReadingMicros: 4 }, timeWaitingMicros: { schemaLock: 3284692 }

在这里对我来说最突出的一行是最后一行，表明它花费了 99.9% 的时间来等待获取称为模式锁的东西。

我检查了这个特定的数据库和集合，结果发现该集合在查询时有 50 个项目，而数据库本身很小（总共不到 1k 个文档）。此外，还有一个关于 的索引myField。

以下是有关我们对 mongodb 的特定用法的一些其他数据，这些数据可能相关：

• 通过为每个客户拥有一个数据库来实现多租户
• 大多数文件都很小
• 大多数文档在其整个生命周期中都具有相似的大小（我在此处阅读了其他一些文档，其中存在与填充相关的性能问题，并且文档随着大小的增长而移动）
• 客户数据通过文档数量而不是文档大小增长

我一直在监视这些慢速查询一段时间，但我看不到任何模式。就像 mongodb 经常做一些维护任务一样，当时运行的任何查询都被迫等待。

为什么读取查询等待获取模式锁？我能做些什么来消除这个漫长的等待？

Answer 1

这是 WiredTiger 存储引擎的一般架构问题。现在在这里讨论：https : //jira.mongodb.org/browse/WT-5479

长话短说，您打开的文件数量太多了。如果可以，请考虑删除不必要的索引，例如小集合上的索引。您还可以探索 MongoDB 4.2 中引入的新通配符索引