这样我就能够重复使用这些片段，通过这种方式，已经为自己的存储系统添加了片段池。降低了需要创立的文件数量，同时减小了对Linux页面缓存造成的处置压力。通过初步测试，发现片段池机制带来了令人鼓舞的逊色效果。

简介

      而且能够直接处置所有正处于执行当中的查询。GraphDBLinkedIn实时分布式社交图谱服务当中充任着存储层的角色。服务旨在处置简单查询（例如来自LinkedIn成员的一级与二级网络请求）与复杂查询（例如成员之间的距离以及成员之间的关联路径等图谱结果）支持多种节点及边界类型。对应用程序使用我社交图谱的方式进行初步了解。

      而且99%查询都能在微秒级别的延迟之内得到响应（通常延迟为十几微秒）有鉴于此，LinkedIn上的每一个页面视图都会发生多条指向GraphDB查询请求。这意味着GraphDB每秒钟都要处置不可胜数条查询请求。即使GraphDB响应延迟提高到仅仅5毫秒，LinkedIn全局访问效果也将受到严重影响。

      已经发现GraphDB会在使用高峰当中偶尔出现间歇性响应延迟。深入调查了这些高峰时段，2013年的大部分时段。并努力了解Linux内核如何管理NUMA 即非统一内存访问）系统上的虚拟内存。概括来说，针对NUMA 一部分Linux优化存在严重的负面作用，会因此对延迟发生直接性不利影响。认为此次研究的效果足以协助任何一套运行在Linux系统环境下、对延迟要求较高的线数据库系统获得性能改进。经过我优化调整，问题出现几率（例如响应缓慢或者查询超时的出现比例）已经下降到原先的四分之一。

      将共同了解相关背景资料，文章的第一部分。包括：GraphDB数据管理方面的流程大纲、性能问题的具体表示以及Linux虚拟内存管理（简称VMM子系统的运作方式。文章的第二部分，将详细探讨解决方法、指导意见以及结论汇总，旨在通过实验找到问题呈现的根源。最后，将归纳通过此次实例所获得的经验。

本文适合对操作系统运行机制具备一定了解的朋友。

背景资料

1、GraphDB如何管理数据

      将所有数据文件映射到虚拟内存页面当中，GraphDB实质上是一种内存内数据库。读取方面。并始终将其保留在内存中的活动集之下。读取活动具备很强的随机性，指向目标普及整个数据集，且99%请求都要求将延迟控制在微秒级别。一台典型的GraphDB主机能够拥有48GB物理内存，常用内存量为20GB其中15GB用于处置堆外虚拟内存页面映射数据，5GB用于JVM堆。

      拥有一套日志-结构化存储系统。将全部数据划分为以10MB为单位的纯追加部分。目前，而在写入方面。每一台GraphDB主机大约拥有1500个活动部分，其中只有25个能够随时接受写入操作，其它1475个则处于只读状态。

      需要定期对其进行压缩。此外，由于数据采用日志结构化存储方式。由于我所采取的压缩计划比较积极，因此每天每台主机上约有九百个数据片段会被遗弃。换言之，每天每台主机上约有容量达9GB数据文件完全消失，但这还仅仅是LinkedIn全局数据增量中的一小局部。概括来讲，每台48GB主机在运行五天之后页面缓存就会被垃圾堆满。

2、问题症状

      往往会面临数量庞大的直接页面扫描以及内存执行效率低下等困扰，所遇到性能问题主要表示为在使用高峰期GraphDB出现响应延迟。高峰期呈现的同时。具体情况如sar所示。个别情况下，sar-B 下"每秒pqsandpqscand/"列的输出效率将拖慢至每秒100万到500万页面扫描，虚拟内存效率也会降至0%--这些症状往往会继续数小时。

      系统的内存压力却并不明显：这是因为我可以通过/proc/meminfo记录看到大量无效缓存页面。此外，性能表示急剧下滑的过程中。并不是pqscand/中的所有高峰时段都会引发GraphDB延迟问题。

3、最让我感到困惑的两个问题是

      为什么系统内核会对页面进行扫描？1如果系统中不存在明显的内存压力。

      为什么我响应延迟会急剧升高？只有写入线程需要占用新的内存分配，2即使内核开始对页面进行扫描。而且写入与读取线程池是相互独立的因此，为什么实际结果是双方会相互发生影响？

      别担心，正是这些问题的答案促使我对NUMA 系统的Linux优化方案做出调整。需要强调的最终将注意力集中在Linux"区回收（zonereclaim"功能方面。如果大家对于NUMA Linux以及区回收不太了解。会在下一局部内容中做出详细讲解。这些资料的辅助下，大家应该可以顺利理解文章其它局部的论证过程。

4、关于LinuxNUMA 以及区回收的那些事儿

      首先需要明确Linux系统如何处置NUMA 架构。为大家甄选了一部分优秀的讲解资源，要想深入理解问题发生的根源。希望能协助各位快速掌握相关的背景知识：

• JeffFrostLinux中的PostgreSQLNUMA 以及区回收模式》如果大家时间有限，优先推荐各位阅读这篇文章。
• ChristophLamet非统一内存访问概述大家需要着重阅读其中关于Linux如何从NUMA 区中回收内存的局部。
• JeremiColeMySQL交换错乱”问题以及NUMA 架构的影响

同样重要的大家需要理解Linux从页面缓存中使用回收页面的具体机制。

      Linux为每个NUMA 区保管着一组三个页面列表：活动列表、非活动列表以及空闲列表。新页面进行分配时会被从空闲列表转移到活动列表。而LRU算法则负责将页面从活动列表转移到非活动列表，简而言之。而后再由非活动列表转移至空闲列表。下面我为大家推荐一份学习Linux页面缓存管理知识的最佳资料：

• MelGorman:解Linux虚拟内存管理器

      而后尝试关闭掉生产主机上的区回收模式。关闭之后，首先认真阅读了上述资料。性能表示立刻获得显著提升。有鉴于此，决定在本文中详细描述区回收的运作机制以及对性能造成影响的原因。

     如果大家对区回收还不太熟悉，本文的其它内容深入探讨了Linux区回收的相关内容。请首先阅读前文推荐的JeffFrost相关论述。

重现并理解Linux区回收活动

1、设置实验环境

      编写了一款程序，为了理解区回收的触发原理以及区回收如何影响性能表示。用于模拟GraphDB读取与写入活动。以二十四小时为期限运行该程序，前面十七个小时内、开启了区回收模式。而在最后七个小时中，关闭了区回收模式。该程序在整个二十四小时当中不间断地运行，环境中的惟一变化就是第十七小时通过向/proc/sys/vm/zone_reclaim_mod中写入"0"来禁用区回收。

下面我来解读该程序的运行内容：

     全部读取一遍，1将2500个10MB数据文件映射至页面缓存当中。而后取消映射，这样Linux页面缓存当中就充溢着垃圾数据。如此一来，系统的运行状态类似于GraphDB主机在正常运行数天后的情况。

      再随机读取其中的一部分内容。这2500个文件构成了活动集合，2一组读取线程会将另一组2500个10MB文件映射至页面缓存当中。用于模拟GraphDB日常使用中的读取状态。

      写入线程就会从活动集合中随机挑选一个文件、取消其映射并用刚刚创立的新文件加以取代。这一过程旨在模拟GraphDB日常使用中的写入活动。3一组写入进程不时创立10MB文件。一旦某个文件创建完成。

      如果读取线程完成读取所消耗的时间超越100毫秒，4最后。则自动输出该次访问流程的usrsy以及elapstime这使我得以胜利追踪到读取性能的变化轨迹。

      保证主机不会遇到任何形式的内存压力。用于运行该程序的主机拥有48GB物理内存。工作组大约占用了其中的25GB除此之外系统中没有运行其它任何任务。通过这种方式。

2、解区回收机制如何被触发

      系统内核会首先检查首选NUMA 区是否拥有足够的空余内存以及是否存在1%以上可以回收的页面。这一百分比可以调节，当某个进程针对页面发出请求时。并由vm.min_unmapped_ratiosysctl来决定。可回收页面属于由文件支持的页面（即与页面缓存存在映射关系的文件所产生的页面）但其目前并未被映射到任何进程当中。/proc/meminfo中，可以很清楚地看到所谓"可回收页面（reclaimpage"就是那些"活动（文件）-非活动（文件）-被映射"Activefile+Inactivfile-Map内容。

       并搭配如下所示的"低/中/高（low/min/high"标签：那么系统内核如何判断多少空闲内存才够用呢？内存会使用区"水平标志（watermark"通过/proc/sys/vm/min_free_kbyt中的值来进行判断。同时也会检查/proc/sys/vm/lowmem_reserve_ratio中的值。特定主机内经过计算的值会被保存在/proc/zoneinfo当中。

Node 1, zone Normal