Jemalloc每次回收都会判断所有实际应该清理的chunck并对清理做count，这个操作对于高响应要求的系统是很奢侈的，所以我们考虑通过升级jemalloc的版本来优化purge的性能。Redis 4.0版本发布后，性能有很大的改进，并可以通过命令回收内存，我们线上也正准备进行升级，跟随4.0发布的jemalloc版本为4.1，jemalloc的版本使用的在jemalloc的4.0之后版本的arena_purge()做了很多优化，去掉了计数器的调用，简化了很多判断逻辑，增加了arena_stash_dirty()方法合并了之前的计算和判断逻辑，增加了purge_runs_sentinel，用保持脏块在每个arena LRU中的方式替代之前的保持脏块在arena树的dirty-run-containing chunck中的方式，大幅度减少了脏块purge的体积，并且在内存回收过程中不再移动内存块。代码如下：

实际上我们有多个选项。可以使用Google的tcmalloc来代替jemalloc，可以升级jemalloc的版本等等。我们根据上面的分析，尝试通过升级jemalloc版本，实际操作为升级Redis版本来解决。我们将Redis的版本升级到4.0.9之后观察，线上客户端连接超时这个棘手的问题得到了解决。

Redis在生产环境中因其支持高并发，响应快，易操作被广泛使用，对于运维人员而言，其响应时间的要求带来了各种各样的问题，Redis的连接超时问题是其中比较典型的一种，从发现问题，客户端连接超时，到通过抓取客户端与服务端的网络包，内存堆栈定位问题，也被其中一些假象所迷惑，最终通过升级jemalloc（Redis）的版本解决问题，这次最值得总结和借鉴的是整个分析的思路。

张延俊：携程技术保障中心资深DBA，对数据库架构和疑难问题分析排查有浓厚的兴趣。
寿向晨：携程技术保障中心高级DBA，主要负责携程Redis及DB的运维工作，在自动化运维，流程化及监控排障等方面有较多的实践经验，喜欢深入分析问题，提高团队运维效率。