MongoShake
MongoShake copied to clipboard
v2.8.0 高负载
- MongoShake的版本:v2.8.0
- 源和目的MongoDB的版本:MongoDB shell version v4.0.28
- 脱敏后的配置文件和日志文件
你好,
我在同一台服务器给同一个数据库分别使用了v2.6.6和最新版本v2.8.0。
在这我观察到当使用v2.6.6时的负载很低如图下。
在相同的配置下使用v2.8.0时的负载CPU使用率占得很高。
不清楚你现在处于全量还是增量阶段?这个建议网上教程做下CPU分析,看下是什么函数在消耗CPU。
你好,
我现在是处于增量阶段。我已经补发了配置文件和日志文件。 我看的是%CPU=上次更新到现在的CPU时间占用百分比。 如图上,目前观察到v2.8.0 占用了 84.9%,而v2.6.6只使用了2.3%。
那关注下增量的写入量,两个版本一样吗?
是的从我这观察写入量确实相同。 我已经附上了2.6.6版本的日志。 collector_v2_6_6.log.zip
运行环境不一样,建议用perf之类的分析程序做下CPU的分析。
你好,
我之前使用是同一个运行环境,同一个数据库,不同的mongoshake版本进行全到增备份。 我这里给同一个数据库使用了不同的db和collector分别搭建了v2.6.6和v2.8.0传输到同一个目的地。 此数据库目前没有什么写入或修改操作。
以下截图是我用perf来同时检查5秒和10秒内的CPU utilized。这也明显能看见只是启动v2.8.0就占用了蛮多的CPU。
麻烦进一步分析下是哪个函数占用CPU。也请关注下shake的增量日志,get,filter,tps的值是否有很大的差别
这是v2.8.0的分析函数。
这是我观察下来的日志,看了tps并没有很高。
v2.6.6 [2022/09/22 16:16:44 HKT] [INFO] [name=default-0, stage=incr, get=20131, filter=9365, write_success=10765, tps=2, ckpt_times=2376, lsn_ckpt={7146115137118666755[1663834587, 3], 2022-09-22 16:16:27}, lsn_ack={7146115205838143490[1663834603, 2], 2022-09-22 16:16:43}]] [2022/09/22 16:16:49 HKT] [INFO] [name=default-0, stage=incr, get=20137, filter=9367, write_success=10768, tps=1, ckpt_times=2377, lsn_ckpt={7146115214428078082[1663834605, 2], 2022-09-22 16:16:45}, lsn_ack={7146115218723045378[1663834606, 2], 2022-09-22 16:16:46}]] [2022/09/22 16:16:54 HKT] [INFO] [name=default-0, stage=incr, get=20137, filter=9368, write_success=10769, tps=0, ckpt_times=2377, lsn_ckpt={7146115214428078082[1663834605, 2], 2022-09-22 16:16:45}, lsn_ack={7146115223018012673[1663834607, 1], 2022-09-22 16:16:47}]] [2022/09/22 16:16:59 HKT] [INFO] [name=default-0, stage=incr, get=20145, filter=9371, write_success=10773, tps=2, ckpt_times=2377, lsn_ckpt={7146115214428078082[1663834605, 2], 2022-09-22 16:16:45}, lsn_ack={7146115265967685635[1663834617, 3], 2022-09-22 16:16:57}]] [2022/09/22 16:17:04 HKT] [INFO] [name=default-0, stage=incr, get=20151, filter=9374, write_success=10776, tps=0, ckpt_times=2378, lsn_ckpt={7146115278852587522[1663834620, 2], 2022-09-22 16:17:00}, lsn_ack={7146115278852587524[1663834620, 4], 2022-09-22 16:17:00}]]
v2.8.0 [2022/09/22 16:16:37 HKT] [INFO] [name=default-0, stage=incr, get=9744, filter=5318, write_success=4426, tps=0, ckpt_times=1018, lsn_ckpt={7146115137118666755[1663834587, 3], 2022-09-22 16:16:27}, lsn_ack={7146115162888470530[1663834593, 2], 2022-09-22 16:16:33}]] [2022/09/22 16:16:42 HKT] [INFO] [name=default-0, stage=incr, get=9750, filter=5318, write_success=4426, tps=0, ckpt_times=1018, lsn_ckpt={7146115137118666755[1663834587, 3], 2022-09-22 16:16:27}, lsn_ack={7146115162888470530[1663834593, 2], 2022-09-22 16:16:33}]] [2022/09/22 16:16:47 HKT] [INFO] [name=default-0, stage=incr, get=9757, filter=5322, write_success=4433, tps=1, ckpt_times=1018, lsn_ckpt={7146115137118666755[1663834587, 3], 2022-09-22 16:16:27}, lsn_ack={7146115214428078082[1663834605, 2], 2022-09-22 16:16:45}]] [2022/09/22 16:16:52 HKT] [INFO] [name=default-0, stage=incr, get=9759, filter=5325, write_success=4434, tps=0, ckpt_times=1019, lsn_ckpt={7146115214428078082[1663834605, 2], 2022-09-22 16:16:45}, lsn_ack={7146115218723045378[1663834606, 2], 2022-09-22 16:16:46}]] [2022/09/22 16:16:57 HKT] [INFO] [name=default-0, stage=incr, get=9762, filter=5326, write_success=4436, tps=2, ckpt_times=1019, lsn_ckpt={7146115214428078082[1663834605, 2], 2022-09-22 16:16:45}, lsn_ack={7146115257377751043[1663834615, 3], 2022-09-22 16:16:55}]] [2022/09/22 16:17:02 HKT] [INFO] [name=default-0, stage=incr, get=9772, filter=5330, write_success=4441, tps=2, ckpt_times=1019, lsn_ckpt={7146115214428078082[1663834605, 2], 2022-09-22 16:16:45}, lsn_ack={7146115278852587524[1663834620, 4], 2022-09-22 16:17:00}]] [2022/09/22 16:17:07 HKT] [INFO] [name=default-0, stage=incr, get=9775, filter=5332, write_success=4441, tps=0, ckpt_times=1020, lsn_ckpt={7146115278852587524[1663834620, 4], 2022-09-22 16:17:00}, lsn_ack={7146115278852587524[1663834620, 4], 2022-09-22 16:17:00}]]