我有一个每秒可以生成 20 000 条记录的进程(记录大小约为 30Kb)。我正在尝试尽快将它们插入到 MongoDB 的单个实例中。但我每秒插入约 1500 次，速度不稳定，从每秒 1000 次插入到 2000 次插入不等。问题是什么原因以及如何解决？ :) 这是来自 mongostat 2.5 小时的数据:

设置

我正在使用 8 核、16Gb RAM、150Gb 硬盘、Ubuntu 18.04、MongoDB 4.0 official docker image 在云中运行实例.在同一个实例上运行 2 个工作程序，每个工作程序每秒生成 10 000 条记录，并将它们 insert_many 到 MongoDB 每个 block 中 100 条记录。每条记录分为 cases 和 docs 2 个集合，docs 使用 zlib 压缩。 cases 记录的平均大小约为 1Kb。以随机记录为例:

{'info': {'judge': 'Орлова Олеся Викторовна', 'decision': 'Отменено с возвращением на новое рассмотрение', 'entry_date': datetime.datetime(2017, 1, 1, 0, 0), 'number': '12-48/2017 (12-413/2016;)', 'decision_date': datetime.datetime(2017, 2, 9, 0, 0)}, 'acts': [{'doc': ObjectId('5c3c76543d495a000c97243b'), 'type': 'Решение'}], '_id': ObjectId('5c3c76543d495a000c97243a'), 'sides': [{'name': 'Кузнецов П. В.', 'articles': 'КоАП: ст. 5.27.1 ч.4'}], 'history': [{'timestamp': datetime.datetime(2017, 1, 1, 15, 6), 'type': 'Материалы переданы в производство судье'}, {'timestamp': datetime.datetime(2017, 2, 9, 16, 0), 'type': 'Судебное заседание', 'decision': 'Отменено с возвращением на новое рассмотрение'}, {'timestamp': datetime.datetime(2017, 2, 17, 15, 6), 'type': 'Дело сдано в отдел судебного делопроизводства'}, {'timestamp': datetime.datetime(2017, 2, 17, 15, 7), 'type': 'Вручение копии решения (определения) в соотв. с чч. 2, 2.1, 2.2 ст. 30.8 КоАП РФ'}, {'timestamp': datetime.datetime(2017, 3, 13, 16, 6), 'type': 'Вступило в законную силу'}, {'timestamp': datetime.datetime(2017, 3, 14, 16, 6), 'type': 'Дело оформлено'}, {'timestamp': datetime.datetime(2017, 3, 29, 14, 33), 'type': 'Дело передано в архив'}], 'source': {'date': datetime.datetime(2017, 1, 1, 0, 0), 'engine': 'v1', 'instance': 'appeal', 'host': 'bratsky.irk.sudrf.ru', 'process': 'adm_nar', 'crawled': datetime.datetime(2018, 12, 22, 8, 15, 7), 'url': 'https://bratsky--irk.sudrf.ru/modules.php?name=sud_delo&srv_num=1&name_op=case&case_id=53033119&case_uid=A84C1A34-846D-4912-8242-C7657985873B&delo_id=1502001'}, 'id': '53033119_A84C1A34-846D-4912-8242-C7657985873B_1_'}

docs 记录平均约为 30Kb:

{'_id': ObjectId('5c3c76543d495a000c97243b'), 'data': 'PEhUTUw+PEhFQUQ+DQo8TUVUQSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9V2luZG93cy0xMjUxIj4NCjxTVFlMRSB0eXBlPXRleHQvY3NzPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9EWT48U1BBTiBzdHlsZT0iVEVYVC1BTElHTjoganVzdGlmeSI+DQo8UCBzdHlsZT0iVEVYVC1JTkRFTlQ6IDAuNWluOyBURVhULUFMSUdOOiBjZW50ZXIiPtCgINCVINCoINCVINCdINCYINCVPC9QPg0KPFAgc3R5bGU9IlRFWFQtSU5ERU5UOiAwLjVpbjsgVEVYVC1BTElHTjoganVzdGlmeSI+0LMuINCR0YDQsNGC0YHQuiAwOSDRhNC10LLRgNCw0LvRjyAyMDE3INCz0L7QtNCwPC9QPg0KPFAgc3R5bGU9IlRFWFQtSU5ERU5UOiAwLjVpbjsgVEVYVC1BTElHTjoganVzdGlmeSI+0KHRg9C00YzRjyDQkdGA0LDRgtGB0LrQvtCz0L4g0LPQvtGA0L7QtNGB0LrQvtCz0L4g0YHRg9C00LAg0JjRgNC60YPRgtGB0LrQvtC5INC+0LHQu9Cw0YHRgtC4INCe0YDQu9C+0LLQsCDQni7Qki4sINGA0LDRgdGB0LzQvtGC0YDQtdCyINCw0LTQvNC40L3QuNGB0YLRgNCw0YLQuNCy0L3QvtC1INC00LXQu9C+IOKEliAxMi00OC8yMDE3INC/0L4g0LbQsNC70L7QsdC1INC40L3QtNC40LLQuNC00YPQsNC70YzQvdC+0LPQviDQv9GA0LXQtNC/0YDQuNC90LjQvNCw0YLQtdC70Y8g0JrRg9C30L3QtdGG0L7QstCwIDxTUE.....TlQ6IDAuNWluOyBURVhULUFMSUdOOiBqdXN0aWZ5Ij7QoNC10YjQtdC90LjQtSDQvNC+0LbQtdGCINCx0YvRgtGMINC+0LHQttCw0LvQvtCy0LDQvdC+INCyINCY0YDQutGD0YLRgdC60LjQuSDQvtCx0LvQsNGB0YLQvdC+0Lkg0YHRg9C0INCyINGC0LXRh9C10L3QuNC1IDEwINGB0YPRgtC+0Log0YEg0LzQvtC80LXQvdGC0LAg0L/QvtC70YPRh9C10L3QuNGPINC10LPQviDQutC+0L/QuNC4LjwvUD4NCjxQIHN0eWxlPSJURVhULUlOREVOVDogMC41aW47IFRFWFQtQUxJR046IGp1c3RpZnkiPtCh0YPQtNGM0Y8g0J4u0JIuINCe0YDQu9C+0LLQsDwvUD48L1NQQU4+PC9CT0RZPjwvSFRNTD4=', 'extension': '.html'}

分析

为了弄清楚发生了什么，我使用 docker stats 和 mongostat。关键指标突出显示:

我在数据插入期间收集了 2.5 小时的指标，并从上图中绘制了 CPU %、insert、dirty:

可以看到插入率在脏值达到 20% 的峰值时下降，而在脏值低于 20% 时会上升到 ~2000:

当 CPU 处于事件状态时，Dirty 会下降。可以看到，当 cpu 为 ~300% dirty 开始下降(由于 docker stats 和 mongostat 单独运行)，当 cpu 为 200% 时 dirty 增长回 20% 并且插入速度变慢:

问题

1. 我的分析正确吗？这是我第一次使用 MongoDB，所以我可能错了
2. 如果分析正确，为什么 MongoDB 并不总是使用 300%+ CPU(实例有 8 个内核)来保持 dirty 低和插入率高？是否可以强制它这样做，这是解决我的问题的正确方法吗？

更新

也许 HDD IO 是个问题？

我没有记录 IO 利用率，但是

1. 我记得在插入过程中查看了 cloud.mongodb.com/freemonitoring，有一个名为“磁盘利用率”的图，最大为 50%
2. 目前我的问题是插入率不稳定。我对目前每秒最多 2000 次插入没问题。这意味着当前的硬盘可以处理，对吧？我不明白为什么定期插入速率下降到 1000。

关于分片

目前我正在尝试在单台机器上达到最大性能

解决方案

只需将 HDD 更改为 SSD。

之前:

之后:

在每秒插入约 1500 次的情况下，脏数据稳定在约 5%。插入和 CPU 使用率现在稳定。这是我期望看到的行为。 SSD从本题“Unstable insert rate in MongoDB”的题目来解决问题

最佳答案

使用更好的磁盘肯定会提高性能。您还可以监控其他指标。

• 脏字节百分比表示数据在wiredTiger缓存中被修改但尚未持久化到磁盘。如果磁盘 IOPS 已达到您的配置限制，您应该监控它。使用命令 iostat 监控或从 MongoDB FTDC 数据中获取。
• 当您的 CPU 达到峰值时，监控 CPU 时间是否花在 iowait 上。如果 iowait % 很高，则说明存在 I/O 阻塞，即更快的磁盘或更高的 IOPS 会有所帮助。
• 从 mongostat 输出监控 qrw(排队的读写请求)和 arw(事件的读写请求)。如果这些数字像您的示例输出一样仍然很低，尤其是 qrw，那么 mongo 能够支持您的请求，而无需排队请求。
• 通过将注入(inject)工作转移到其他实例来避免资源竞争。
• 您可以使用不同的磁盘分区来进一步优化 mongo 数据路径和日志位置。
• 观察者通常会忽略客户端(摄取工作人员)的性能。 CPU 峰值可能来自您的工作人员，因此吞吐量较低。使用 top 命令或等效命令监控客户端性能。

希望以上帮助。

关于mongodb - MongoDB中不稳定的插入率，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/54211567/