Question

我们使用具有8核32GB RAM的mongodb 3.4.14。我正在用Jmeter执行负载测试，有70个线程，我有可接受的输出。但是，随着负载的增加，SLA呈指数增长，吞吐量急剧下降。我尝试增加ulimit，下一步是分片，除此之外，我还可以进行其他性能优化吗？

更新

@Jetet，这是发现的地方：

是否有很多聚合查询？您拥有哪种收集结构，即

负载测试在单个聚合查询上运行，并且文档的结构也具有相同的字段集。固定文档大小会有所帮助吗？我该怎么办？

是否有很多嵌套数组？

答案：没有嵌套查询。

是单个实例还是副本集？尝试将副本集放入具有不同节点的读写权限。

当前，我们只希望在单个节点上运行。

查询是否从多个集合中返回数据？

否，只有1个收藏集。

检查您的实例是页面错误的操作百分比是多少？

在有500个用户的情况下，我看不到太多页面错误，只有2位数字。

在高锁定/排队期间检查日志中是否具有高nscanned或scanAndOrder的操作，并相应地建立索引。

如何检查？

检查查询中是否有CPU密集型运算符，例如$ all，$ push / $ pop / $ addToSet，以及对大型文档的更新，尤其是对大型数组（或大型子文档数组）的更新。

是，在上述负载下，CPU已满，并且响应被延迟。我们正在进行groupBy，然后按限制排序。

如果您的数据库是大量写入操作，请记住，每个数据库一次只能写入一个CPU（由于该线程持有写入锁定）。考虑将部分数据移至其自己的数据库中。

我们的数据库通常读得很重，该馆藏每天都会填充一次。

除此之外，我尝试通过将以下代码放入for循环中来进行简单的测试：

Document findQuery = new Document("userId", "Sham");
FindIterable<Document> find = collection.find(findQuery);
MongoCursor<Document> iterator = find.iterator();

使用执行程序启动该过程：

ExecutorService executorService = Executors.newFixedThreadPool(100);

即使执行此操作，它的返回速度也很慢，大约需要900毫秒。

1个请求=每个请求150ms

100个请求=每个请求900ms

当我看到500个用户的统计信息如下时：

insert query update delete getmore command dirty used flushes vsize   res qrw arw net_in net_out conn                time
    *0    *0     *0     *0       0     1|0  0.0% 0.0%       0  317M 28.0M 0|0 0|0   156b   45.1k    3 Oct 12 15:31:19.644
    *0    *0     *0     *0       0     1|0  0.0% 0.0%       0  317M 28.0M 0|0 0|0   156b   45.1k    3 Oct 12 15:31:20.650
    *0    *0     *0     *0       0     3|0  0.0% 0.0%       0  317M 28.0M 0|0 0|0   218b   46.1k    3 Oct 12 15:31:21.638
    *0    *0     *0     *0       0     2|0  0.0% 0.0%       0  317M 28.0M 0|0 0|0   158b   45.4k    3 Oct 12 15:31:22.638
    *0    *0     *0     *0       0     1|0  0.0% 0.0%       0  317M 28.0M 0|0 0|0   157b   45.4k    3 Oct 12 15:31:23.638
    *0   376     *0     *0       0   112|0  0.0% 0.0%       0  340M 30.0M 0|0 0|0  64.9k   23.6m   26 Oct 12 15:31:24.724
    *0    98     *0     *0       0   531|0  0.0% 0.0%       0  317M 27.0M 0|0 0|0   109k   6.38m    3 Oct 12 15:31:25.646
    *0    *0     *0     *0       0     2|0  0.0% 0.0%       0  317M 27.0M 0|0 0|0   215b   45.6k    3 Oct 12 15:31:26.646
    *0    *0     *0     *0       0     1|0  0.0% 0.0%       0  317M 27.0M 0|0 0|0   157b   45.1k    3 Oct 12 15:31:27.651
    *0    *0     *0     *0       0     2|0  0.0% 0.0%       0  317M 27.0M 0|0 0|0   159b   45.8k    3 Oct 12 15:31:28.642

Answer 1

这还取决于您要触发的查询的类型，请检查是否存在以下提到的要点-

是否有很多聚合查询？什么样的收藏你有没有结构
是否有很多嵌套数组？
是不是单一实例或副本集？尝试将副本集与read一起放置并写入其他节点。
查询是否从中返回数据多个收藏？
检查您的实例是页面错误的操作百分比是多少？
在高锁定/排队期间检查日志中是否具有高nscanned或scanAndOrder的操作，并相应地建立索引。
检查查询中是否有CPU密集型运算符，例如$ all，$ push / $ pop / $ addToSet，以及对大型文档的更新，尤其是对大型数组（或大型子文档数组）的更新。
如果您的数据库是大量写入操作，请记住，每个数据库一次只能写入一个CPU（由于该线程持有写入锁定）。考虑将部分数据移至其自己的数据库中。

这是随着时间的推移会降低性能的几件事。我在这里介绍了最常见的用例，但是请check this post以获得更多的见解。

Answer 2

请检查您的硬件是否受到限制，磁盘是系统中的最大瓶颈。查看硬件是否不受限制：

top/htop => cpu percentage
iostat -x 1 => sysstat tool to see disk r/w limits (%util)

MongoDB在负载下运行缓慢

更新

2 个答案: