AWS中的MongoDB性能问题

Question

我们有以下MongoDB设置：

基础设施

3个在AWS中运行的副本集。此时，所有节点都位于同一可用性区域，并且都是i3。大型实例。其中2个节点在NVME驱动器上托管DB数据，1个节点在配置IOPS的EBS卷上托管它。

数据

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

我们每个客户都有一个数据库——大约5.5万个。

每个数据库都包含几个具有特定于帐户的数据的集合。这些数据并没有什么特别奇妙的地方，但有些集合除了默认的_id上的索引之外，还有索引。

作者写道

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

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

问题

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

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

DB本身没有响应。通过终端，我可以获得rs.status（）和rs.printslavereplicationfo（），它现在显示出主从机之间的差距越来越大。

从远程客户端连接到数据库会在检索副本集时陷入困境。

日志中没有在主要或次要日志中突出的内容。下面是来自primary的dump片段。

有什么想法吗？

谢谢

2018-12-18T18:46:43.238 0000 I网络[conn39304]从172.30.1.180:52756 conn39304接收到客户端元数据：{driver:{name:{networkinterfaceeasio RS'，version:“3.6.8”}，os:{type:“Linux”，name:“PRETTY_name=“Debian GNU/Linux 9（stretch）”，architecture:“x86_64”，version:“Kernel 4.9.0-8-amd64”}2018-12-18T18:46:44.059 0000 I命令[ftdc]服务器状态非常慢：{basic:0之后、断言：0之后、后台刷新：0之后、连接：0之后、dur:0之后、额外信息：0之后、globalLock:0之后、锁：0之后、logicalSessionRecordCache:0之后、网络：0之后、opLatencies:0之后、opcounters:0之后、opcountersRepl:0之后、安全性：0之后、storageEngine:0之后、tcmalloc:0之后、事务：0之后、transportSec:0之后urity:0，在wiredTiger:1058之后，在结束时：1058}2018-12-18T18:46:44.498 0000 I网络[conn39305]从172.30.1.193:58142 conn39305:{driver:{name:{NetworkInterfaceASIO RS]，版本：“3.6.7”}，os:{type:“Linux”，name:“PRETTY_name=“Debian GNU/Linux 9（stretch）”，architecture:“x86_64”，version:“Kernel 4.9.0-8-amd64”}2018-12-18T18:46:44.500 0000 I ACCESS[conn39305]在本地2018-12-18T18:46:44.540 0000 I ACCESS[conn39304]在本地2018-12-18T18:46:45.758 0000 I COMMAND上成功认证为主体u系统[PeriodicTaskRunner]任务：UnusedLockCleaner获取：243ms 2018-12-18T18:47:22.360 0000 I网络[listener]连接从172.30.1.180:52758接受#39306（245个连接现在打开）2018-12-18T18:47:22.399 0000 I网络[conn39306]从172.30.1.180:52758 conn39306]接收到客户端元数据：{驱动程序：{name:“NetworkInterfaceASIO RS”，版本：“3.6.8”，os:{type:“Linux”，name:“PRETTY_name=“Debian GNU/Linux 9（stretch）”，architecture:“x86_64”，version:“Kernel 4.9.0-8-amd64”}I网络[conn39307]从172.30.1.193:58144接收客户端元数据conn39307:{driver:{name:“NetworkInterfaceASIO RS”，版本：“3.6.7”}，os:{type:“Linux”，name:“PRETTY_name=“Debian GNU/Linux 9（stretch）”，architecture:“x86_64”，version:“Kernel 4.9.0-8-amd64”}在本地2018-12-18T18:47:35.377 0000 I访问[conn137]在本地2018-12-18T18:47:35.554 0000 I访问[conn137]在本地2018-12-18T18:47:35.554 0000 I访问[conn137]在本地2018-12-18T18:47:37.797 0000 I访问[conn137]在本地2018-12-18T18:46.685成功认证为主体U系统0000 I网络[listener]连接已从172.30.1.187:33484#39308（247个连接现已打开）2018-12-18T18:47:46.699 0000 I网络[conn39308]接收来自172.30.1.187:33484 conn39308的客户端元数据：{驱动程序：{名称：“mongo csharp驱动程序”，版本：“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访问[conn39308]已在admin 2018-12-18T18:48:02.362 0000 I网络[listener]连接上成功身份验证为主要tdservice 2018-12-18T18:02.362 0000 I网络[conn39309]已从172.30.1.180:52760#39309（248连接现已打开）2018-12-18T18:48:02.419 0000 I网络[conn39309]接收来自172.30.180:52760的客户端元数据：{驱动程序：{name:“NetworkInterfaceASIO RS”，版本：“3.6.8”}，os:{type:“Linux”，name:“PRETTY_name=“Debian GNU/Linux 9（stretch）”，architecture:“x86_64”，version:“Kernel 4.9.0-8-amd64”}I网络[conn39310]从172.30.1.193:58146接收客户端元数据conn39310:{driver:{name:“NetworkInterfaceASIO RS”，version:“3.6.7”}，os:{type:“Linux”，name:“PRETTY_name=”Debian GNU/Linux 9（stretch）”，architecture:“x86_64”，version:“Kernel 4.9.0-8-amd64”}2018-12-18T18:48:02.510 0000 I ACCESS[conn39310]在本地系统上成功地通过了主体身份验证

Answer 1

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