java - MongoDB 在负载下执行缓慢

Question

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

更新

@Jeet，这是调查结果:

1. is there lot of aggregation queries? What kind of collection structure do you have i.e

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

2. is there a lot of nested arrays?

答案:没有嵌套查询。

3. Is it a single instance or replica set? Try putting a replica set with read and write to different node.

目前我们只想在单节点上运行。

4. Are the queries returning data from multiple collections?

没有，只有 1 个集合。

5. Check your instance is page-faulting for how much % of operations?

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

6. Check your logs for operations with high nscanned or scanAndOrder during periods of high lock/queue, and index accordingly.

如何检查？

7. Check your queries for CPU-intensive operators like $all, $push/$pop/$addToSet, as well as updates to large documents, and especially updates to documents with large arrays (or large subdocument arrays).

是的，在上述负载下 CPU 已满并且响应延迟。我们正在做一个 groupBy，然后用 limit 排序。

8. if your database is write-heavy, keep in mind that only one CPU per database can write at a time (owing to that thread holding the write lock). Consider moving part of that data into its own database.

我们的数据库主要是读取量大，集合将每天填充一次。

除此之外，我尝试通过将以下代码放在 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 个请求 = 每个请求 150 毫秒

100 个请求 = 每个请求 900 毫秒

当我看到 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

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

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

随着时间的推移，这会降低性能。我在这里介绍了最常见的用例，但请 check this post了解更多信息。