数据库内核月报 － 2016 / 04

问题

通常我们使用MongoDB的时候，客户端（driver）和MongoDB之间都是使用长连接，但是在某些场景下、某些driver仍然只能使用短连接进行连接，比如PHP。就在我们阿里云数据库MongoDB版商业化后没多久，我们就遇到了一个用户短连接过多导致的性能问题。

这个问题的症状是MongoD的CPU使用率居高不下，16个核都跑满了，影响到了用户的正常使用。

排查

首先想到的当然是看看有没有很多慢查询，针对存在的慢查询都建议用户建了索引后，情况还是没有好转。这时我们观察到用户的driver不断有短连接上来，基本上身份认证完执行个操作后很快就断开。会不会是短连接的问题导致呢？因为阿里云数据库MongoDB版出于安全考虑，强制打开了身份认证，我们知道 MongoDB3.0 后使用的身份认证机制是SCRAM-SHA1，这是需要进行一些 CPU 密集型操作比如哈希计算等的。通过profile工具进行诊断后，我们发现 CPU 热点非常集中，主要消耗在读取 /dev/urandom 来生成随机数，这需要通过系统调用进入内核态。再结合监控，确实 CPU 都消耗在sys而不是user。以下为profile工具诊断图：

对照一下源码就知道了，这是因为在认证过程中需要生成一串叫做server-nonce的随机字符串（具体的认证过程及这个随机字符串的作用可参照MongoDB中使用的SCRAM-SHA1认证机制。在Linux平台下，是通过这个/dev/urandom（Linux上提供了两个随机数生成的特殊设备文件，还有一个是/dev/random，这两个的区别是从/dev/urandom 中读取是非阻塞的，具体可再自行google或看man手册。）来生成随机数的。其原理是利用当前系统的熵池来计算出一定数量的随机比特，然后将这些比特作为字节流返回。熵池就是当前系统的环境噪音，因此其随机效果还是比较好的。不过有利必有弊，这个/dev/urandom的性能就不怎么好了。要使用这个来生成随机数，首先要进行系统调用，这涉及用户态到内核态的切换。其次，为了避免两个并发读返回同样的结果，在内核中使用了spinlock，因此在多线程并发从/dev/urandom中读时，性能会急剧下降。这个东东设计之初是为了安全，而不是性能。因此建议的做法是使用/dev/urandom来初始化用户态的随机数，而不是每个请求都从这里取。

解决

既然知道了问题，那么解决也就好办了，当然是想办法使用一个性能较好，随机性又不差的方案来替换这个/dev/urandom。我们使用了一个用户态的随机数生成器，效果非常明显，CPU使用率从100%降到10%。

以下为优化前后CPU使用率对比图：

其中红色、蓝色、绿色分别为关闭Auth、打开Auth（优化前）和打开Auth（优化后）。

目前阿里云数据库MongoDB版已经全面使用了性能优化版，所以各位使用短连接（如PHP driver）的客官们可以放心使用了。