17000商户并行Cron任务致MongoDB查询变慢问题求助

背景信息 #

• 执行环境：Golang开发的Cron定时任务，MongoDB服务器配备128GB内存，Cron任务运行在独立机器上
• 数据架构：17000个商户对应17000个独立MongoDB数据库
• 任务负载：Cron每15分钟执行一次，某次运行中需处理6000个商户，每个商户发送5条提醒，每条触发20-30次CRUD操作

问题现象 #

• Cron任务启动初期查询速度正常，运行一段时间后逐渐变慢
• MongoDB服务器内存使用率最高达85%，剩余可用内存约15GB
• MongoDB日志出现异常：

  "msg":"Failed to gather storage statistics for slow operation","attr":{"opId":1533607,"error":"lock acquire timeout"
  Checkpoint has been running for 165 seconds and wrote: 35000 pages (1160 MB)

问题原因分析 #

1. Checkpoint长时间运行引发锁竞争 #

MongoDB默认使用WiredTiger存储引擎，会定期创建checkpoint将内存中的脏页刷写到磁盘。当checkpoint运行时间过长（日志显示165秒），会持续占用存储层的锁资源，导致其他业务操作（包括慢查询统计、常规CRUD）无法获取锁，进而触发lock acquire timeout错误。

此次场景中，Cron任务短时间内产生大量脏页，超出了WiredTiger后台刷写线程的处理能力，迫使checkpoint持续运行，挤占了正常业务的资源。

2. 多数据库架构导致资源分散 #

17000个独立数据库意味着WiredTiger需要为每个库维护独立的缓存、锁表和元数据。尽管服务器剩余15GB内存，但缓存被分散到大量数据库中，单个商户的数据集无法被高效缓存，导致频繁的磁盘IO，进一步加剧了checkpoint的刷写压力。同时，跨多库的并发操作会放大锁竞争的复杂度，与长时间运行的checkpoint形成资源争抢。

3. Cron任务的突发流量过载 #

6000个商户的并发处理带来了瞬间的高负载：6000525=750000次CRUD操作集中在15分钟窗口内，短时间内产生的脏页积累速度远快于WiredTiger的刷写速度，导致checkpoint需要一次性处理大量数据，运行时间被大幅拉长。

排查与优化建议 #

• 调整WiredTiger Checkpoint参数：增大storage.wiredTiger.checkpoint.size（默认2GB），减少checkpoint触发频率；或调整storage.wiredTiger.checkpoint.interval，避开Cron任务的运行高峰。
• 优化Cron并发策略：将6000个商户的处理拆分为多个批次，控制并发数，比如每次处理300-500个商户，降低峰值负载，减少脏页的瞬间积累。
• 重构数据架构：考虑将多个商户的数据合并到单个数据库的不同集合中，减少元数据和缓存的分散，提升缓存命中率，降低锁竞争的复杂度。
• 检查磁盘IO性能：确认MongoDB服务器的磁盘读写能力，若使用机械硬盘建议更换为SSD；若为SSD，监控IO队列长度是否过高，必要时升级存储硬件。
• 优化查询与索引：梳理每条提醒对应的20-30次查询，确保所有查询都有合适的索引，避免全表扫描，降低磁盘IO和CPU消耗。

内容的提问来源于stack exchange，提问作者sahil garg