MongoDB性能测试报告
陶仪（https://www.doczj.com/doc/2c3304711.html,/taoyi518/ https://www.doczj.com/doc/2c3304711.html,/taoyilovemaxs）
2012-7-24
1.测试点
1、磁盘占用情况
2、批量导入性能
3、查询性能
4、系统稳定性
2.测试环境
1、硬件环境
Cpu:E5440 @ 2.83GHz 2core
Memory:8G
2、软件环境
Os: Linux apptest 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
mongodb-linux-x86_64-2.0.5
3、测试数据集
采用简单的行数据，每行包括long,int,date,string,double类型字段各一个
4、测试数据集
每个数据集为1000万数据（每行5个字段，包括一个较长的字符串），磁盘占用空间4.0G。
3.测试结果
a)single node插入
连接（192.168.28.33: 27018）插入1000W数据共耗时:2690.797s,平均每秒插入3717
连接（192.168.28.31: 27017）插入1000W数据共耗时: 2597.609s,平均每秒插入3850行
b)single node查询
测试1000W数据查询耗时的情况，
图1
结论：
2、当线程数达到16或者32左右时，系统吞吐量基本饱和。
c)single node插入性拐点测试基础数据量：21358297条记录
结论：
平均每秒约插入数据约6975条记录
结论：
随着插入记录条数的增加时间增大
说明：
在启动8线程，每个线程insert 500w数据，导致服务down掉，重新启动警
d)single node查询性拐点测试数据量：20365562条记录
图2
结论：
调整Mongodb的cpu muna控制级别为all级别后，随着线程的增加（同图1比较）性能有所提升。
当请求量达到6W次是查询时间明显加大。
结论：
随着线程的增加，并发查询次数减少，导致查询效率提高。Shard+3replset测试性能
insert command vsize res faults netIn netOut conn repl time 3838 3837 512m 4m 2 928k 626k 34 RTR 16:39:47 3865 3864 512m 4m 0 935k 630k 34 RTR 16:39:48 3297 3297 512m 4m 0 797k 538k 34 RTR 16:39:49 3707 3708 512m 4m 0 897k 605k 34 RTR 16:39:50 3701 3703 512m 4m 0 895k 604k 34 RTR 16:39:51 3968 3969 512m 4m 0 960k 647k 34 RTR 16:39:52 3799 3802 512m 4m 0 919k 620k 34 RTR 16:39:53 4162 4162 512m 4m 0 1m 679k 34 RTR 16:39:54 4041 4041 512m 4m 0 977k 659k 34 RTR 16:39:55 4128 4126 512m 4m 0 998k 673k 34 RTR 16:39:56
2、查询性能测试（数据量：1亿条
场景：磁盘数据量：28G（数据量24G，其它4G）
结论：
随着线程的增加查询性能有所提高，在1亿条记录平均没查询一次需要6-8ms。
在亿级别的数据上查询速度是非常可观的。
由于磁盘
在测试的过程中还发现几个问题需要值得注意：
1）在数据量很大的情况下，对服务进行重启，那么服务启动的初始化阶段，虽然可以接受数据的查询和修改，但是此时性能很差，因为mongodb会不断把数据从磁盘换入内存，此时的IO压力非常大。
2）在数据量很大的情况下，如果服务没有正常关闭，那么Mongodb启动修复数据库的时间非常可观，在1.8中退出的-dur貌似可以解决这个问题，我简单测试了一下，开启dur对插入和查询性能影响都不是很大。
3）在使用Sharding的时候，Mongodb时不时会对数据拆分搬迁，这个时候性能下降很厉害，虽然从测试图中看不出（因为我每一次测试都会测试比较多的迭
代次数），但是我在实际观察中可以发现，在搬迁数据的时候每秒插入性能可能会低到几百条。
4）对于数据的插入，如果使用多线程并不会带来性能的提高，反而还会下降一点性能（并且可以在http接口上看到，有大量的线程处于等待）。
5）在整个测试过程中，批量插入的时候遇到过几次连接被远程计算机关闭的错误，怀疑是有的时候Mongodb不稳定关闭了连接，但是也仅仅是在数据量特别大的时候遇到几次。