【性能】大页内存 (HugePages)在通用程序优化中的应用

目录

1. 背景

2. 基于指纹的音乐检索简介

3. 原理

4. 小页的困境

5. 大页内存的配置和使用

6. 大页内存的优化效果

7. 大页内存的使用场景

8. 总结

LD_PRELOAD用法

---

原文：大页内存(HugePages)在通用程序优化中的应用_姚光超的专栏-CSDN博客_大页内存

今天给大家介绍一种比较新奇的程序性能优化方法—大页内存(HugePages)，简单来说就是通过增大操作系统页的大小来减小页表，从而避免快表缺失。这方面的资料比较贫乏，而且网上绝大多数资料都是介绍它在Oracle数据库中的应用，这会让人产生一种错觉：这种技术只能在Oracle数据库中应用。但其实，大页内存可以算是一种非常通用的优化技术，应用范围很广，针对不同的应用程序，最多可能会带来50%的性能提升，优化效果还是非常明显的。在本博客中，将通过一个具体的例子来介绍大页内存的使用方法。

       在介绍之前需要强调一点，大页内存也有适用范围，程序耗费内存很小或者程序的访存局部性很好，大页内存很难获得性能提升。所以，如果你面临的程序优化问题有上述两个特点，请不要考虑大页内存。后面会详细解释为啥具有上述两个特点的程序大页内存无效。

1. 背景

       近期一直在公司从事听歌识曲项目的开发，详细内容可参考：基于指纹的音乐检索，目前已上线到搜狗语音云开放平台。在开发的过程中，遇到一个很严重的性能问题，单线程测试的时候性能还能达到要求，但是在多线程进行压力测试的时候，算法最耗时的部分突然变慢了好几倍！后来经过仔细调试，发现最影响性能的居然是一个编译选项-pg，去掉它之后性能会好很多，但是还是会比单线程的性能慢2倍左右，这就会导致系统的实时率达到1.0以上，响应能力严重下降。

       通过更加仔细的分析，我们发现系统最耗时的部分是访问指纹库的过程，但是这部分根本就没有优化余地，只能换用内存带宽更高的机器。换用内存带宽更高的机器确实带来了不少性能的提升，但是还是无法达到要求。就在山重水尽的情况下，无意中看到MSRA的洪春涛博士在微博中提到他们用大页内存对一个随机数组的访问问题进行优化获得了很好的性能提升。然后就向他求助，终于通过大页内存这种方法使系统性能进一步提升，实时率也降到了0.4左右。圆满达成目标！

2. 基于指纹的音乐检索简介

检索过程其实和搜索引擎一样，音乐指纹就和搜索引擎中的关键词等价，指纹库就等价于搜索引擎的后台网页库。指纹库的构造和搜索引擎的网页库也是一样，采用倒排索引形式。如下图：

图1 基于指纹的倒排索引表

只不过指纹都是一个int型的整数(图示只占用了24位)，包含的信息太少，所以需要提取很多个指纹完成一次匹配，大约是每秒几千个的样子。每获得一个指纹都需要访问指纹库获得对应的倒排列表，然后再根据音乐id构造一个正排列表，用来分析哪首音乐匹配上，如下图：

图2 统计匹配的相似度

最终的结果就是排序结果最高的音乐。

目前指纹库大约60G，是对25w首歌提取指纹的结果。每一个指纹对应的倒排列表长度不固定，但是有上限7500。正排列表的音乐个数也是25w，每一首音乐对应的最长时间差个数为8192。单次检索的时候会生成大约1000个左右的指纹(甚至更多)。

通过上面的介绍，可以看出基于指纹的音乐检索(听歌识曲)共有三部分：1.提取指纹；2.访问指纹库；3.排序时间差。多线程情况下，这三部分的时间耗费比例大约是：1%、80%和19%，也即大部分时间都耗费在查找指纹库的操作上。更麻烦的一点是，指纹库的访问全部是乱序访问，没有一点局部性可言，所以cache一直在缺失，常规的优化方法都无效，只能换成内存带宽更高的服务器。

不过正是由于上述的特点—耗费内存巨大(100G左右)、乱序访存且