AWS中的MongoDB性能问题

时间:2018-12-18 19:20:36

标签: mongodb amazon-web-services

我们有以下MongoDB设置:

基础结构

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

数据

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

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

每个数据库包含一些具有特定于帐户的数据的集合。数据没有什么特别花哨的地方,但是除了默认情况下_id上的索引之外,有些集合确实还有索引。

著作

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

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

问题

在大多数情况下,此设置可以正常运行。问题出在我们需要对所有客户帐户执行操作时,例如删除早于X的事件,或向每个帐户添加某些数据。在这两种情况下,该过程都会在帐户ID列表上进行操作,并完成其工作。

这两种情况都具有相同的问题表现。该过程快速启动,并迅速通过许多帐户。随着它不断超过约2万个帐户,它开始变慢。减速变得越来越长,并开始影响数据库读取。从上次运行开始,在处理了约41k个帐户后,它变得无响应(但此时已导致读取失败)。

数据库本身会做出响应。在终端上,我可以获取rs.status()并可以获取rs.printSlaveReplicationInfo(),现在这表明PRIMARY和SECONDARIES之间的差距越来越大。

从远程客户端连接到数据库陷入了获取副本集的麻烦。

在日志中没有任何东西可以在PRIMARY或SECONDARIES上脱颖而出。以下是来自primary的转储片段。

有什么想法或想法吗?

谢谢!


2018-12-18T18:46:43.238 + 0000 I NETWORK [conn39304]从172.30.1.180:52756 conn39304接收了客户端元数据:{驱动程序:{名称:“ NetworkInterfaceASIO-RS”,版本:“ 3.6.8”} ,操作系统:{类型:“ Linux”,名称:“ PRETTY_NAME =“ Debian GNU / Linux 9(拉伸)””,体系结构:“ x86_64”,版本:“内核4.9.0-8-amd64”}} 2018-12-18T18:46:44.059 + 0000我命令[ftdc] serverStatus非常慢:{在基本之后:0,在断言之后:0,在backgroundFlushing:0之后,在连接之后:0,在dur:0之后,在extra_info之后: 0,在globalLock:0之后,在锁定之后:0,在logicalSessionRecordCache:0之后,在网络上:0,在opLatency:0之后,在opcounters:0之后,在opcountersRepl:0之后,在repl:0之后,在安全性之后: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(拉伸)“”,体系结构:“ x86_64”,版本:“内核4.9.0-8-amd64”}} 2018-12-18T18:46:44.500 + 0000 I访问[conn39305]在本地成功验证为主体__system 2018-12-18T18:46:44.540 + 0000 I访问[conn39304]在本地成功验证为主体__system 2018-12-18T18:46:45.758 + 0000我命令[PeriodicTaskRunner]任务:UnusedLockCleaner花费了:243ms 2018-12-18T18:47:22.360 + 0000我接受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(拉伸)“”,体系结构:“ x86_64”,版本:“内核4.9.0-8-amd64”}} 2018-12-18T18:47:22.401 + 0000 I访问[conn39306]在本地成功验证为主体__system 2018-12-18T18:47:22.465 + 0000我从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(拉伸)“”,体系结构:“ x86_64”,版本:“内核4.9.0-8-amd64”}} 2018-12-18T18:47:22.579 + 0000 I访问[conn39307]在本地成功验证为主体__system 2018-12-18T18:47:35.372 + 0000 I访问[conn137]在本地成功验证为主体__system 2018-12-18T18:47:35.374 + 0000 I访问[conn137]在本地成功验证为主体__system 2018-12-18T18:47:35.377 + 0000 I访问[conn137]在本地成功验证为主体__system 2018-12-18T18:47:35.554 + 0000 I访问[conn137]在本地成功验证为主体__system 2018-12-18T18:47:37.797 + 0000 I访问[conn137]在本地成功验证为主体__system 2018-12-18T18:47:46.685 + 0000我接受172.30.1.187:33484#39308的NETWORK [listener]连接(现已打开247个连接) 2018-12-18T18:47:46.699 + 0000 I NETWORK [conn39308]从172.30.1.187:33484 conn39308接收了客户端元数据:{驱动程序:{名称:“ mongo-csharp-driver”,版本:“ 0.0.0.0”}, os:{类型:“ 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上成功认证为主体tdservice 2018-12-18T18:48:02.362 + 0000 I NETWORK [侦听器]连接已从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(拉伸)“”,体系结构:“ x86_64”,版本:“内核4.9.0-8-amd64”}} 2018-12-18T18:48:02.421 + 0000 I访问[conn39309]在本地成功验证为主体__system 2018-12-18T18:48:02.470 + 0000 I NETWORK [侦听器]连接已从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(拉伸)“”,体系结构:“ x86_64”,版本:“内核4.9.0-8-amd64”}} 2018-12-18T18:48:02.510 + 0000 I访问[conn39310]在本地成功验证为主体__system

1 个答案:

答案 0 :(得分:0)

因此,只是此问题的更新。可疑的数据设置(每个客户都有一个数据库)似乎与问题高度相关。当我们重组数据使其位于单个数据库中并扩展集合以明确标识客户时,所有问题都消失了。 看来,维护“数据库”的开销对于这种体系结构来说是过高的。