AWS 中的 MongoDB 性能问题答案

【问题标题】：MongoDB perfromance issues in an AWSAWS 中的 MongoDB 性能问题
【发布时间】：2020-01-16 10:28:13
【问题描述】：

我们有以下 MongoDB 设置：

基础设施

在 AWS 中运行的 3 个副本集。此时，节点都在同一个可用区，都是 i3.large 实例。其中 2 个节点将数据库数据托管在 NVME 驱动器上，1 个节点将其托管在具有预置 IOPS 的 EBS 卷上。

数据

数据设置有点可疑，但根据我对文档的理解应该可以正常工作。

我们每个客户都有一个数据库 - 其中大约有 55,000 个。

每个数据库都包含一些包含特定帐户数据的集合。数据没有什么特别花哨的，但除了 _id 默认情况下存在的索引之外，一些集合确实有索引。

写作

写入的大部分数据都是与客户帐户相关的事件。这些被收集到一个队列 (SQS) 中，当前由单个线程写入。写入器缓冲大约 15 分钟的数据，然后确定将数据写入哪个数据库并刷新它。该进程是一个 C# Windows 服务。

一些写操作绕过队列（被认为是高优先级）。其中包括帐户创建和其他高优先级事件。

问题

在大多数情况下，此设置运行良好。当我们需要对所有客户帐户执行操作时，问题就出现了——例如删除早于 X 的事件，或将某些数据添加到每个帐户。在这两种情况下，该过程都对帐户 ID 列表进行操作，并执行其操作。

这两种情况的问题表现形式大致相同。该过程快速启动并快速通过许多帐户。随着它不断超过约 2 万个帐户，它开始放缓。减速变得越来越长，并开始影响数据库读取。截至上次运行，在处理了大约 41k 个帐户后它变得无响应（但此时已经导致读取失败）。

数据库本身会做出响应。从终端，我能够获取 rs.status() 并能够获取 rs.printSlaveReplicationInfo()，它现在显示 PRIMARY 和 SECONDARIES 之间的差距越来越大。

从远程客户端连接到数据库在检索副本集时卡住了。

日志中没有任何内容在 PRIMARY 或 SECONDARIES 中脱颖而出。下面是来自主要转储的 sn-p。

有什么想法或想法吗？

谢谢！

2018-12-18T18:46:43.238+0000 I NETWORK [conn39304] 从 172.30.1.180:52756 conn39304 收到客户端元数据：{驱动程序：{名称：“NetworkInterfaceASIO-RS”，版本：“3.6.8”} , os: { type: "Linux", name: "PRETTY_NAME="Debian GNU/Linux 9 (stretch)"", 架构: "x86_64", 版本: "Kernel 4.9.0-8-amd64" } } 2018-12-18T18:46:44.059+0000 I COMMAND [ftdc] serverStatus 非常慢：{基本后：0，断言后：0，backgroundFlushing：0，连接后：0，dur：0，extra_info后： 0，globalLock 后：0，locks 后：0，logicalSessionRecordCache：0 后，network：0 后，opLatencies：0 后，opcounters：0 后，opcountersRepl：0 后，repl：0 后，security：0 后，storageEngine 后： 0，tcmalloc 之后：0，事务之后：0，transportSecurity 之后：0，wiredTiger 之后：1058，结束：1058 } 2018-12-18T18:46:44.498+0000 I NETWORK [conn39305] 从 172.30.1.193:58142 conn39305 收到客户端元数据：{驱动程序：{名称：“NetworkInterfaceASIO-RS”，版本：“3.6.7”}，操作系统： { 类型：“Linux”，名称：“PRETTY_NAME="Debian GNU/Linux 9 (stretch)”，架构：“x86_64”，版本：“内核 4.9.0-8-amd64”} } 2018-12-18T18:46:44.500+0000 I ACCESS [conn39305] 成功认证为本地的主体__system 2018-12-18T18:46:44.540+0000 I ACCESS [conn39304] 成功认证为本地主体__system 2018-12-18T18:46:45.758+0000 我命令 [PeriodicTaskRunner] 任务：UnusedLockCleaner 耗时：243ms 2018-12-18T18:47:22.360+0000 I NETWORK [listener] 连接从 172.30.1.180:52758 #39306 接受（现在打开 245 个连接） 2018-12-18T18:47:22.399+0000 I NETWORK [conn39306] 从 172.30.1.180:52758 conn39306 收到客户端元数据：{驱动程序：{名称：“NetworkInterfaceASIO-RS”，版本：“3.6.8”}，操作系统： { 类型：“Linux”，名称：“PRETTY_NAME="Debian GNU/Linux 9 (stretch)”，架构：“x86_64”，版本：“内核 4.9.0-8-amd64”} } 2018-12-18T18:47:22.401+0000 I ACCESS [conn39306] 成功认证为本地的主体__system 2018-12-18T18:47:22.465+0000 I NETWORK [listener] 连接从 172.30.1.193:58144 #39307 接受（现在打开 246 个连接） 2018-12-18T18:47:22.539+0000 I NETWORK [conn39307] 从 172.30.1.193:58144 conn39307 收到客户端元数据：{驱动程序：{名称：“NetworkInterfaceASIO-RS”，版本：“3.6.7”}，操作系统： { 类型：“Linux”，名称：“PRETTY_NAME="Debian GNU/Linux 9 (stretch)”，架构：“x86_64”，版本：“内核 4.9.0-8-amd64”} } 2018-12-18T18:47:22.579+0000 I ACCESS [conn39307] 成功认证为本地的主体__system 2018-12-18T18:47:35.372+0000 I ACCESS [conn137] 成功认证为本地的主体__system 2018-12-18T18:47:35.374+0000 I ACCESS [conn137] 成功认证为本地的主体__system 2018-12-18T18:47:35.377+0000 I ACCESS [conn137] 成功认证为本地的主体__system 2018-12-18T18:47:35.554+0000 I ACCESS [conn137] 成功认证为本地的主体__system 2018-12-18T18:47:37.797+0000 I ACCESS [conn137] 成功认证为本地的主体__system 2018-12-18T18:47:46.685+0000 I NETWORK [listener] 连接从 172.30.1.187:33484 #39308 接受（现在打开 247 个连接） 2018-12-18T18:47:46.699+0000 I NETWORK [conn39308] 从 172.30.1.187:33484 conn39308 收到客户端元数据：{驱动程序：{名称：“mongo-csharp-driver”，版本：“0.0.0.0”}，操作系统：{类型：“Windows”，名称：“Microsoft Windows NT 6.2.9200.0”，架构：“x86_64”，版本：“6.2.9200.0”}，平台：“.NET Framework 4.5”} 2018-12-18T18:47:46.770+0000 I ACCESS [conn39308] 已成功通过管理员身份验证为主体 tdservice 2018-12-18T18:48:02.362+0000 I NETWORK [listener] 连接从 172.30.1.180:52760 #39309 接受（现在打开 248 个连接） 2018-12-18T18:48:02.419+0000 I NETWORK [conn39309] 从 172.30.1.180:52760 conn39309 收到客户端元数据：{驱动程序：{名称：“NetworkInterfaceASIO-RS”，版本：“3.6.8”}，操作系统： { 类型：“Linux”，名称：“PRETTY_NAME="Debian GNU/Linux 9 (stretch)”，架构：“x86_64”，版本：“内核 4.9.0-8-amd64”} } 2018-12-18T18:48:02.421+0000 I ACCESS [conn39309] 成功认证为本地的主体__system 2018-12-18T18:48:02.470+0000 I NETWORK [listener] 连接从 172.30.1.193:58146 #39310 接受（现在打开 249 个连接） 2018-12-18T18:48:02.489+0000 I NETWORK [conn39310] 从 172.30.1.193:58146 conn39310 收到客户端元数据：{驱动程序：{名称：“NetworkInterfaceASIO-RS”，版本：“3.6.7”}，操作系统： { 类型：“Linux”，名称：“PRETTY_NAME="Debian GNU/Linux 9 (stretch)”，架构：“x86_64”，版本：“内核 4.9.0-8-amd64”} } 2018-12-18T18:48:02.510+0000 I ACCESS [conn39310] 成功认证为本地的主体__system

【问题讨论】：

MongoDB very slow deletes的可能重复
您可能需要考虑查看可能重复问题的答案中注明的 TTL 索引：docs.mongodb.com/manual/tutorial/expire-data
谢谢。我们已经查看了 TTL 指数。问题是这也发生在插入...（使用一些数据更新每个帐户）
不幸的是，在推荐的解决方案方面我无能为力。我鼓励你在你的节点上添加一些监控，看看你的资源利用率在这些峰值周围是什么样子的。我想 I/O 是一个大问题，但也要看看 RAM、CPU 或任何其他可能证明有问题的东西。如果证明 I/O 问题太大，您可能需要考虑水平扩展（即分片）。

标签： mongodb amazon-web-services

【解决方案1】：

所以只是关于这个问题的更新。可疑的数据设置（每个客户都有一个数据库）似乎与问题高度相关。当我们重组数据使其位于单个数据库中并扩展集合以明确识别客户时，所有问题都消失了。似乎维护“数据库”的开销对于这种架构来说是令人望而却步的。

【讨论】：