一、背景

微信支付的账单系统是方便用户获取交易记录，针对不同的用户群，账单也分为三类：

• 个人账单：针对普通用户群，这类用户特点是基数大，单个用户数据量小，使用账单系统主要是获取列表以及基础统计；
• 商户账单：针对商户用户群，这类用户特点是基数小，单个用户数据量非常大，使用账单系统主要是获取列表，并且在获取列表时需要支持丰富查询条件；
• 业务账单：针对用户群介于普通用户和商户之间，比如微商或面对面小商户，使用账单系统主要是获取列表以及丰富统计功能；

目前账单平台为微信支付的这三类账单提供写入、存储和查 询服务，基本架构如下：

账单平台主要包括两部分：

• 逻辑侧：业务侧直接对接模块，主要是降低业务接入成本，提高接入效率；
• 存储侧：包含ES以及接入层ESProxy，接入层对上屏蔽索引划分机制，方便上层使用；

当前微信支付对整体质量要求非常高，体现在可用性方面是需要达到99.99%，同样账单平台也需要达到甚至超过该要求。但是在ES及系统环境未做优化的情况下，读写成功率是没有达到要求，在个人账单ES索引场景下，写成功率为99.85%，读成功率为99.95%，所以这里亟需优化。

二、内存回收慢优化

问题分析

针对读写成功率低问题，我们首先查看存储侧接入层ESProxy超时失败的情况，对应如下图：

可以看出接入层访问ES节点出现了大量超时，在排除接入层自身的问题后，基本上把问题源锁定到ES节点。 通过进一步确认ES节点负载情况（如下图），机器会出现CPU抖动，而抖动时上层会出现超时，这就表明读写成功率低是CPU抖动导致的，于是我们重心就是解决CPU抖动问题。

那么是什么原因导致ES节点的CPU抖动呢？首先我们先确定CPU抖动时系统具体在做什么，根据已有经验，很有可能是ES热点线程或GC导致的，但是在分析CPU抖动时user和system进程占比情况，其中user进程CPU占比基本没有变化，而system进程CPU却增长很多，由于ES热点线程或GC是user进程，所以排除了这里的影响。通过系统相关统计以及perf得到下面现象：

• 抖动时系统在大量扫描可回收内存

• 系统在不断进行内存回收

• 系统分配内存时出现了失败

通过这三个现象，我们也得出了一个结论，CPU抖动是因为内存不足导致。

优化方案

明确了抖动问题原因后，那么我们接下来的优化方向就是保证有足够的空闲内存，避免内存不断回收而出现CPU抖动。 针对内存不足问题，我们首先确认系统当前的内存分布情况，具体数据如下：

进一步分析如下：

• ES节点内存主要是被JVM以及PageCache内存占用
• Jvm内存是被java独占，该部分内存是不会被回收
• PageCache内存由操作系统维护，该部分内存是可以被回收的

正常情况下，如果系统内存不足，则内核通过回收PageCache的内存即可提供足够的空闲内存，即不会内存不足的情况；反过来说，当前出现内存不足，则说明PageCache未被正常回收，于是针对内存优化则聚焦到PageCache回收问题上。 针对PageCache回收问题，首先我们先明确什么因素导致PageCache不能及时回收，其中MMap就可能导致PageCache不能正常回收，原因是MMap后应用程序会引用到这部分内存，则内核在回收内存时会忽略这部分内存。而ES节点读取文件的方式默认就是MMap，整体的内存关联关系如下图：

既然MMap方式会导致PageCache不能及时回收，那么自然考虑是采用其他方式替换MMap去访问文件，在Java中即可采用NIO方式读取文件，对应内存关联关系如下：

采用NIO方式访问文件，PageCache内存只被操作系统维护，则内核可以及时回收PageCache以保证足够的内存使用，这样就解决了内存不足问题，进而解决CPU抖动问题，从而提高读写成功率； 但是采用NIO访问文件也存在问题，即数据会多一次内存复制，会导致延迟方面比MMap方式的高，经过测试发现延迟会高30%左右，这样的结果也不是我们想要的，于是我们考虑将两者结合起来，目的是加快内存回收的同时降低延迟，采取的策略是根据访问频率来确定文件的读写方式（即高频采用MMap方式，这样可以保证延迟低，低频采用Nio方式，这样可以加快内核回收PageCache），具体不同文件类型读取方式如下表：

优化效果

采用MMap+Nio的方式后，通过测试验证：

• 延迟方面和MMap基本一致
• 内存回收方面也比MMap好

采用MMap+Nio组合方式上线后，对应现网写成功率由99.85%提升到99.99%。

三、高阶内存优化

问题分析

在系统运行一段时间后，现网的成功率逐渐降低，由99.99%降低到99.97%，对应接入层的超时失败也相应增多，有了之前的经验，我们相应查看了ES节点的负载情况，发现仍然有CPU抖动的现象（如下图）。考虑到之前已经优化了内存回收慢的问题，此时应是新的问题导致的CPU抖动，于是接下来优化点依旧是解决抖动。

和之前分析CPU抖动问题一样，我们先确认CPU抖动系统在做什么。通过perf分析，如下图所示：

采样的结果可以明确CPU抖动时，系统在进行内存碎片整合（即有compact_zone()等函数调用），这就意味着此时系统高阶内存是不足，为了进一步验证当前的高阶内存不足，通过 cat /proc/buddyinfo 查看当前系统空闲内存的分布情况，如下图所示：

分析上面数据可以得出，当前空闲内存有4G左右，86%的内存是0阶内存，大于等于2阶的高阶内存占比只有4%左右，这里验证当前空闲内存是基本都是碎片化的，碎片化内存示意图如下所示：

优化方案

明确了当前的问题后，那么接下来重点就是考虑将碎片化的内存变成连续内存。前文我们明确了当前ES节点的内存主要有两部分组成，分别是JVM内存和PageCache内存，并且在我们现网环境中，这两部分内存基本上是独立的（当前现网机器内存有两个NODE，每个NODE占了一半的物理内存，其中JVM和PageCache分布在不同的NODE上），这就意味着我们可以只优化PageCache间的内存碎片，这样就可以满足我们需求；对应优化流程如下：

具体分为两个步骤： 1、释放内存：释放PageCache内存，保证新的空闲内存尽可能连续，具体的处理措施是echo 1 > /proc/sys/vm/drop_cache 2、保留一定空闲内存：目的是避免内存的不断申请和回收，导致内存碎片化再次变的严重，具体处理措施是限制PageCache的大小（这里依赖tlinux的实现），具体的命令是echo 36 > /proc/sys/vm/pagecache_limit_ratio

优化效果

经过上述的优化之后，系统的空闲内存分布如下：

此时的空闲也是在4G左右，但是大于等于2阶的高阶内存占比达到95%左右，即高阶内存当前是非常充足的，并且机器的CPU几乎没有抖动（如下图所示）。

在现网进行相应调整之后，读写成功率提升效果如下：

• 写成功率由99.85%提升到99.999%
• 读成功率由99.95%提升到99.999%

四、结论

针对账单平台的ES系统的读写成功率未满足要求，进行了如下优化措施： 1、内存回收慢优化：优化ES文件读取方式，加快内存回收，降低CPU在内存回收方面消耗； 2、高阶内存不足优化：整理碎片化内存，保证有充足高阶内存，降低CPU在内存碎片整理消耗； 经过上述优化措施后，ES系统的读写成功率达到99.999%，超出当前的可用性要求，保障ES在生产环境稳定性。

五、参考

1、Node Hot threads API 2、Physical Page Allocation 3、Describing Physical Memory