奇怪的性能低下

背景

昨晚需要跑一批数据到mongo中，采用jmeter读取数据文件向服务端发送请求的方式，将数据库跑入数据库。
数据量：200w
mongo与服务端均部署在同一台机器上。

现象

在服务器上执行jmeter脚本，但是数据惨不忍睹

测试截图

看了服务器的cpu 和内存的使用率，发现cpu（24核）只有67%，内存只有20%（512G）。并发量只有200，明显对于服务端的压力不大，排除硬件。

后来将并发量降低至50，数据依然惨不忍睹。

猜测

怀疑是数据库的索引没有加，但是服务端是会自动建立索引的，进入mongo查看索引，发现都建立了。
决定开始mongo 慢查询，看看是否是数据入库时过慢造成的， 因为测试前数据库是空的，随着数据的进入，伴随着insert及query操作。

慢查询分析流程

通过慢查询日志，定位每条语句的执行时间，比如超过了200ms的，那么就需要针对这个进行优化。
优化步骤：

1. 用慢查询日志（system.profile）找到超过200ms的语句
2. 然后再通过.explain()解析影响行数，分析为什么超过200ms
3. 决定是不是需要添加索引

---

开启慢查询

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性能低下的问题。

后续有待继续研究。