Redis跑ARM上那些事儿，性能调优和适配经验分享

前段时间，我们团队把一个用了很久的Redis服务从x86的服务器搬到了新的ARM服务器上，这事儿听起来就是换个环境运行，应该很简单，但实际上遇到了不少稀奇古怪的问题，也积累了一些经验，下面我就把我们遇到的坑和怎么填坑的过程,原原本本地讲一遍。

为啥要往ARM上搬？

最开始的原因很简单，就是成本，公司采购了一批基于ARM架构的服务器，据说性价比高，功耗也低，我们一看，Redis这种内存型的应用，对CPU指令集应该没那么挑剔吧？而且社区里也说ARM版Redis挺稳定的，为了省钱,我们就决定做一次迁移。

编译安装，第一个坑就来了

在x86上，我们习惯用make && make install一把梭，几乎从来没出过错，但在ARM服务器上，第一次编译就报错了，错误信息一大堆，根本看不懂，后来查了资料（资料来自Redis的GitHub issues里别人提的问题），发现是编译器的版本太老了，ARM架构相比x86还是“年轻人”,需要新一点的工具链来支持。

解决办法是升级了我们服务器上的GCC编译器，换成新版本后，再编译就一次通过了，所以第一条经验：在ARM上编译Redis，确保你的GCC编译器版本足够新,别用那些老掉牙的系统自带的版本。

跑起来了，但总觉得有点“慢”

服务启动后，我们用常规的压测工具去测试，看平均响应时间，好像跟之前在x86上差不多，但总感觉哪里不对，就是不稳定，偶尔会冒出几个响应时间特别长的请求,像卡了一下似的。

我们一开始怀疑是网络，排查了半天没问题，然后又怀疑是ARM服务器的硬件问题，但其他服务跑得挺正常的，我们把目光投向了Redis的配置项，经过一番搜索和尝试（参考了阿里云技术博客上关于ARM架构数据库优化的文章），问题出在一个叫transparent huge pages（透明大页）的Linux内核特性上。

这个功能的本意是好的，想提高内存管理的效率，但在Redis这种对内存操作非常频繁的场景下，ARM架构上这个功能反而容易引起延迟毛刺，我们试着用命令echo never > /sys/kernel/mm/transparent_hugepage/enabled把它关掉之后，再压测，那种偶尔的卡顿现象就基本消失了，所以第二条经验：在ARM服务器上运行Redis，强烈建议关闭操作系统的透明大页功能,这对稳定性很重要。

内存分配器的选择

Redis的性能和内存分配器关系很大，在x86上，我们默认用的jemalloc就表现很好，在ARM上，我们一开始也是用jemalloc，但压测到极限情况时,发现内存碎片有点高。

我们尝试换成了libc的malloc，结果性能下降比较明显，后来看到一篇论文（好像是华中科技大学某个团队发的，关于不同架构下内存分配器性能分析的），里面提到在ARM架构下，jemalloc的某些默认参数可能不是最优的，我们照着论文里的一些建议，调整了jemalloc的配置，比如设置MALLOC_CONF="background_thread:true"来启用后台线程进行内存整理，情况就好多了，第三条经验：在ARM上不要轻易更换内存分配器，还是首选jemalloc，但可以尝试调整它的高级参数来适应ARM的特点。

关于持久化的额外注意点

Redis的持久化（RDB和AOF）是CPU和IO密集型的操作，在ARM上，我们注意到在生成RDB快照（也就是做持久化）的时候，对主线程的延迟影响似乎比在x86上要稍微大一点点，虽然没出大问题，但我们为了保险起见,做了两件事：

1. 把save的触发条件设置得更宽松一些,避免在业务高峰期间频繁触发持久化。
2. 如果使用了AOF，更多地使用everysec策略，而不是always，以减少IO压力。 这算是一个观察，不算严格的优化,但觉得值得提一下。

总结一下

把Redis从x86迁移到ARM上，并不是简单的复制粘贴，它能够稳定运行，但要想获得最佳性能，需要一些额外的调优,我们的核心经验就是三点：

1. 编译环境要新,别让陈旧的工具链拖后腿。
2. 操作系统内核参数要调,特别是关掉透明大页。
3. 内存分配器要细调，用jemalloc但要根据ARM的特性进行微调。

经过这一番折腾，现在我们的Redis在ARM服务器上跑得又快又稳，确实帮公司省下了不少成本，希望我们遇到的这些事儿，能给也想在ARM上部署Redis的朋友提个醒,少走点弯路。