通过对MongoDB进行性能压测，发现在不同配置下性能表现各异。单机开启journal时，最高qps约为6000；关闭journal可提升至7000。在sharding环境中，开启journal的主从配置qps为5000，而关闭journal时可达6500。混布数据节点导致性能下降至3000qps，建议采用pre-sharding策略解决数据分布不均问题。
一直想知道mongodb的性能如何，今天对压测结果做了下总结
数据：每条记录约208 Byte，仅压测update操作(存在就修改，不存在则插入)。
配置1：单机的mongodb，单表记录数6百万左右。
1.启用journal约6500 qps, 每隔60秒有一次抖动，因为配置成60秒将内存数据落盘一次，落盘期间磁盘的tps会大增，约700，其他时刻仅50左右的tps。
2.不启用journal稳定在7000qps。没有抖动。磁盘的tps和情况1一样，只是未开启journal，即使落盘也不影响性能。
3.同一台机器启动两个不相干的mongodb服务，都启用journal，分别由两个client写入数据。初始时总写入qps有2*6000左右，
一段时间后会降到6000左右，服务A的qps约2000，服务B的qps约4000。关闭服务B的压力，服务A的qps能上升到6000。
因此可以推测一台机器上，开启journal时只能维持6000左右的写入qps。
配置2：
一个sharding， 一主两从部署在不同的机器上，单表记录数8百万左右。
1. 主库从库都开启journal，当单表8百万记录时，update操作约5000qps，比单机性能略低，可能是主从同步的原因。和单机一样每隔60秒落盘会有一次抖动。
2. 主库关闭journal，从库关闭journal，update操作稳定在6500qps。
3. 在机器A上同时部署两
最低0.47元/天 解锁文章
扫一扫
1543
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
