背景
昨晚需要跑一批数据到mongo中，采用jmeter读取数据文件向服务端发送请求的方式，将数据库跑入数据库。
数据量：200w
mongo与服务端均部署在同一台机器上。
现象
在服务器上执行jmeter脚本，但是数据惨不忍睹
测试截图
看了服务器的cpu 和内存的使用率，发现cpu（24核）只有67%，内存只有20%（512G）。并发量只有200，明显对于服务端的压力不大，排除硬件。
后来将并发量降低至50，数据依然惨不忍睹。
猜测
怀疑是数据库的索引没有加，但是服务端是会自动建立索引的，进入mongo查看索引，发现都建立了。
决定开始mongo 慢查询，看看是否是数据入库时过慢造成的， 因为测试前数据库是空的，随着数据的进入，伴随着insert及query操作。
慢查询分析流程
通过慢查询日志，定位每条语句的执行时间，比如超过了200ms的，那么就需要针对这个进行优化。
优化步骤：
- 用慢查询日志（system.profile）找到超过200ms的语句
- 然后再通过.explain()解析影响行数，分析为什么超过200ms
- 决定是不是需要添加索引
开启慢查询
Profiling级别说明
- 0：关闭，不收集任何数据。
- 1：采集慢查询数据，默认是100毫秒。
- 2：采集所有数据
开启profiling
#查看状态：级别和时间
> db.getProfilingStatus()
{ "was" : 0, "slowms" : 100 }
#查看级别
> db.getProfilingLevel()
0
#设置级别
> db.setProfilingLevel(1)
{ "was" : 0, "slowms" : 100, "ok" : 1 }
#设置级别和时间
> db.setProfilingLevel(1,200)
{ "was" : 2, "slowms" : 100, "ok" : 1 }
需要注意的是，以上操作如果是在collection下操作，只对该collection有效。如果需要对整个db有效，需要在db下执行。每次执行后返回的结果是修改前的状态。
慢查询分析
{
"op" : "insert", #操作类型，有insert、query、update、remove、getmore、command
"ns" : "fingerprint.T_DEVICE_FP_ANDROID", #操作集合
"query" : {
"insert" : "T_DEVICE_FP_ANDROID",
"ordered" : true,
"documents" : [
{
"_id" : ObjectId("58c143a5d8a7db667f13629b"),
"_class" : "*************",
}
]
},
"ninserted" : 1,
"keyUpdates" : 0, #索引更新的数量，改变一个索引键带有一个小的性能开销，因为数据库必须删除旧的key，并插入一个新的key到B-树索引
"writeConflicts" : 0,
"numYield" : 0, #该操作为了使其他操作完成而放弃的次数。通常来说，当他们需要访问还没有完全读入内存中的数据时，操作将放弃。这使得在MongoDB为了放弃操作进行数据读取的同时，还有数据在内存中的其他操作可以完成
"locks" : {
"Global" : {
"acquireCount" : {
"r" : NumberLong(1),
"w" : NumberLong(1)
}
},
"Database" : {
"acquireCount" : {
"w" : NumberLong(1)
}
},
"Collection" : {
"acquireCount" : {
"w" : NumberLong(1)
}
}
},
"responseLength" : 40,
"protocol" : "op_query",
"millis" : 1601, #消耗的时间（毫秒）
"execStats" : {
},
"ts" : ISODate("2017-03-09T11:59:34.972Z"),
"client" : "10.100.1.200",
"allUsers" : [ ],
"user" : ""
}
此处发现millis 数据很大，一个insert操作需要1.6s。需要进行优化。
总结
上面的只是一个例子，实际中，我当时是在query遇到问题，一个query执行了2800ms。后来发现是有两个字段没有建索引导致的。但是依然没有解决insert性能低下的问题。
后续有待继续研究。
