内存碎片是否拖慢了你的程序？

现象描述：近日，公司HPC平台用户频繁反应任务无法正常运行或运行一般会停止无输出，或读取或写入数据时某些数据块耗时比正常速度高几百甚至上千倍。
针对此现象，对集群反复排查了多次，未发现任何异常，日志中也无明显报错信息，从监控系统中观察出现问题节点的CPU、内存、网络、存储等相关资源使用情况，均无太高负载，占用率都非常低。所以分析应该不是存储或硬件资源瓶颈导致的。后来将服务器系统重启后再提交任务，发现运行恢复正常。但一段时间后问题又会出现，至此问题始终未能得到根本性解决，不可能没隔一段时间就把服务器进行重启。

经过反复排查测试，使用top命令观察进程状态，发现每次任务运行中断时均会出现khugepage进程，占用一个cpu核资源。我们来了解下什么是Hugepage。

Hugepage，即大内存页
网上查询大内存页的优点，解释如下：
巨大的页面可以通过减少缺页提升性能（一次缺页分配大块的内存），还可以通过减少虚拟地址到物理地址的转换成本（减少转化次数），甚至可以避免地址转换。如果处理器必须转换一个虚拟地址，它必须通过多达四层页表。处理器保持一个“翻译后备缓冲器（TLB）的缓存的转换结果。TLB的容量很小，一般是128条指令转换、32条数据转换。非常容易被填满，从而必须进行大量的地址转换。例如：2m的页大小只需要一个tlb项，而4k的页大小就需要512个tlb项。通过内核地址使用大内存页，可以减少tlb的压力。
基于以上原因，使用大内存页的程序会运行的很快。

再来分析我们程序特点。由于GPU无法直接读取磁盘上数据，必须经过内存转换，由cpu先将数据读取到内存，GPU在读取内存中数据进行计算。和开发了解到每次任务中断的位置为读取数据或写入数据阶段，而不是计算阶段。而且任务运行的特点是将一个大文件按照固定大小的文件块，划分多次进行读取，直到全部读完。再进行GPU计算，计算过程中伴随结果数据的输出。

任务的特点是频繁进行内存申请释放操