Abstract
GRAM为大量广泛使用的图算法提供一种高效可扩展图形引擎。它旨在被设计在单机环境中扩展到多核机器中，并扩展到集群中的多个服务器，在评估的图算法上，与现有的分布式图引擎相比，它的性能提高很多，通常幅度要大一个数量级。 GRAM还能够处理比以前测试的图数据更大的图数据。 特别是，使用64台服务器（1,024个物理内核），它在具有超过一万亿条边的合成图上以140秒一次迭代执行PageRank迭代，为图形引擎树立了一个新的里程碑。
GRAM的效率和可扩展性来自于利用多核和RDMA优势的明智的架构设计。 GRAM使用简单的基于消息传递的Scale体系架构来扩展以展现固有的并行性。它受益于被特地设计成具有多核意识的基于RDMA的通信协议栈，可平衡地保持并行性并允许通信和计算的重叠。 由于资源碎片化(大图被划分到大量的机器中去)，高度的并行性往往以降低效率为代价。 GRAM配备了一个自适应机制，用于评估并行性的Cost和benefit以决定适当的配置。 综合起来，这些机制使GRAM能够高效地扩大规模。
1.Introduce
图结构很流行，并提供关于关系和关系的宝贵信息。 例如，社交图揭示每个人的影响和社区的形成。分布式图处引擎已经提出（比如Pregel、PowerGraph、Graphx、PowerLyra），他们主要的见解是通过沿着边进行计算和通信的多次迭代，通常情况下每轮迭代会被barrier隔离。图计算对于集群规模来说特别具有挑战性，因为在这样的工作量中图非常难以分割并且很小的随机访问占主导地位。然而，我们看到真正的需求是处理越来越大的图形，数千亿乃至数万亿的边[10,19]。 即使对现有的图形引擎进行了详细的性能研究[15]，对这种图形引擎的扩展和cost仍缺乏了解。
我们提供了一个新的图形引擎GRAM，它利用数据中心现有的硬件，多核服务器，集群中丰富的内存以及支持RDMA（远程直接内存访问）的高速网络[17]。 通过对性能，可扩展性和成本的仔细研究，GRAM的设计和实施得到了进一步的指导，并有以下关键设计选择。
首先，GRAM采用一种非常简单的模型来进行扩展，我们通过消息传递与线程（甚至是服务器内的线程）进行关联，每个线程与每个核心关联。我们选择消息传递而不是共享内存原语，甚至对于服务器内部的情况也是如此，因为我们的评估结果（第5部分）揭示，通过充分的批量发送消息，消息传递展现出比共享内存原语更好的性能。因为更好的局部性和更少的core之间的通信（线程之间的通信？机器内部消息通信？为什么会有更少的机器内部的通信？）。 该模型充分体现了固有的硬件级并行性。 该模型的简单性使得易于理解软件栈引入的任何潜在的可扩展瓶颈，同时允许扩展的高效实现。
其次，为了向外扩展机器规模，GRAM包含了一个基于多核的RDMA通信栈。 通信栈通过细粒度消息缓冲池来最大化并行性，以减少不同通信线程对之间的干扰（每次发送一个消息就生成相对应的消息缓冲池）。由于图计算经常涉及跨越迭代的Barrier，因此跨线程的负载平衡对于减少整体计算延迟至关重要。 GRAM通信协议栈的设计需要仔细考虑：采用轻量级协调机制的对称和均衡设计，并支持NUMA感知分配，以应对服务器NUMA体系结构带来的底层异构。
使用RDMA的好处不仅仅是实现网络通信中的高带宽和低延迟。由于RDMA引起的CPU减少，GRAM抓住了重叠计算的机会。我们观察到令人惊讶的结果，其中显示的GRAM能够在大规模集群服务器上实现与在本地服务器上扩展相同的扩展：通信成本虽然显着高于本地服务器，但可以通过重叠计算来掩盖。
掩蔽通信成本和缩放比例之间存在着紧张关系。由于集群规模缩放增加了并行性水平并（因此）降低了每个线程上的计算成本，因此可能不再有足够的计算来掩盖通信成本。并行性的增加也可能导致碎片化，数据和缓冲区以更细的粒度进行分区，从而降低内存使用效率和通信通道效率。 在这些情况下，GRAM采用粗略粒度的复用和批量处理，以提高通信效率。
GRAM已经在一个由支持RDMA的高速网络连接的集群上得到了充分的实施和广泛的研究。我们用通用图计算算法来评估GRAM，如页面排序，弱连接组件（WCC）和单源 最短路径（SSSP），在各种代表性图形上，大小从10亿到1万亿不等。 评估结果不仅表明GRAM可以扩展规模，还可以揭示可扩展性的重要限制因素并验证我们的设计选择。总体而言，GRAM在单核上实现了高度优化的单线程实现，具有较低的竞争率（速度降低了约33％），在4个内核上执行时间更短，可扩展至1,024个内核，处理超过1个十亿个边缘。
虽然GRAM是为特定的（RDMA能力）环境设计和评估的，但我们专注于展示我们详细分析的见解，这对于构建高效和可扩展的计算引擎是非常重要的，即使在不同的配置中也是如此设计权衡取舍。
本文的其余部分安排如下。 第2节描述了GRAM目标的图类算法及其影响GRAM设计的特征。 我们在第3部分介绍GRAM的总体架构设计，并在第4部分介绍GRAM的通信堆栈。评估结果显示在第5部分，随后讨论了我们在第6部分从GRAM中学到的一般课程。我们调查相关工作在第7节，并在第8节结束。
2.Graph Computation: An Overview
最近关于图计算的工作[13,14,23,24]指出了一个基于顶点的图并行计算模型。给定一个图G = {V，E}，每个顶点程序P被执行 顶点v∈V并且与相邻实例P（u）相互作用，其中（u，v）∈E。顶点程序通常保持与顶点和边相关联的应用特定状态，在相邻顶点之间交换状态值，并在图计算过程中计算新值。 例如，PageRank图计算的每次迭代都包含一个顶点，将相关联的秩值除以它的度数，然后根据当前值和邻居值计算其新秩值。
许多图计算算法，例如PageRank，在批量同步并行模型[38]中迭代执行，其中在两次连续迭代之间插入屏障。 这样的模型很容易理解，并且倾向于提供明确的收敛性质。虽然一些图形引擎[14,24]采用同步模型，但其他[13,23]采用顶点程序的异步调度来避免障碍。 然而最近的研究[15]表明GraphLab[23]中的异步调度由于锁争用，缺少消息批处理和昂贵的终止检测而表现不如其PageRank的同步调度。我们迄今的经验也有利于同步模型。因此，GRAM专注于优化同步情况，而且还为连接组件等图形算法引入了松散模型，其中允许每次迭代中的多跳传播有助于减少迭代次数并加速收敛。
3.GRaM Architecture
GRAM的设计是由第2节中描述的图计算的特性驱动的：（i）在顶点层次上进行图并行计算，（ii）在每次迭代中内存的随机访问占主导，以及（iii）跨越迭代的barrier。 GRAM因此采用简单的扩展体系结构来利用图计算的固有并行性，如图1所示。在此体系结构中，每个工作线程都分配给专用的CPU核心并拥有一个图分区。在计算开始时，所有图分区都被加载到主内存中。 GRAM使用与Grace [32]中使用的数据结构类似的数据结构来布局内存中的图形分区，其中顶点数组包含顶点数据（例如，rank值）和包含由对应源顶点分组的边的边数组。
在图计算过程中，每对线程通过消息传递机制进行通信，而不管它们是否在同一台服务器上运行。我们选择消息传递，而不是共享内存原语，即使是在同一台服务器上的线程，主要是为了允许打包一些小的CPU核之间的随机数据访问。简单的架构还可以轻松确定缩放图计算的限制因素，因为架构完全展现了CPUcore级并行性。 优化通信开销显然是集群规模伸缩的关键。此外，由于在图计算中常见使用Barrier，跨CPU core之间的负载平衡是另一个重要目标，因为在每次迭代中，计算时间都由最慢的线程支配。
现代多核架构通常为所有内核提供共享内存抽象以访问任何内存地址。 对于单核多核服务器上的图形工作负载采用这种抽象似乎是一种自然的选择。 几个现有的图形引擎采用了这种选择，例如GraphLab /Power-Graph [13,23]，Grace [32]和Chronos [16]。 令人惊讶的是，我们的分析表明，与使用消息传递相比，共享内存模型实际上为图计算提供次优性能，很大程度上是由于图工作负载中占主导地位的小随机访问模式。图形往往是复杂和高度空间的：它们很难划分或以一种展现良好局部性的方式布局：相邻顶点不能总是放在一起。典型的图计算工作负载如PageRank，Spectral Partitioning [37]和稀疏矩阵向量复制会产生大量随机数据访问，这些数据访问通常需要跨越CPU core和服务器才能在邻居之间传播数据。共享内存开销的一个来源是锁抢占的开销，因为顶点可能具有公共邻居，并且不同线程可能想要更新与同一顶点关联的值。开销的另一个来源可能是由于错误共享或core之间的错误数据局部性访问导致的跨CPU core间通信成本。 通过消息传递，这些随机的线程间（服务器间）数据访问通常可以跨越顶点自然地进行打包批量的发送消息。
图2说明了线程间消息传递对缓解核心间通信开销的潜在好处之一。示例图包含三个顶点Va，Vb和Vc，分区中的Vc分配给Core0，Va和Vb（它们是Vc的邻居）分配给Core1。 考虑从Vc到Va和Vb的顶点数据传播，并且假设Va和Vb的顶点数据在不同的缓存行中。 如果Core0上的线程通过共享内存原语直接更新Va和Vb，则这些操作可能涉及到两个缓存行级别的CPU Core之的间通信。相反，通过消息传递，Core0上的线程首先将这两个更新打包到消息缓冲区的单个缓存行中，然后缓存行数据将由Core1上的线程抓取，只有一次缓存行级别的CPU Core之间的通信。 从根本上讲，随着消息传递，通过批量将随机的内核数据访问模式转换为顺序模式，以改善局部性并最大化通信吞吐量。即使消息传递将核心内存复制的额外开销引入消息缓冲区，这种好处对于图形计算工作负载也是非常重要的。
消息传递是服务器间通信的自然选择，我们的分析还表明，与RDMA提供的共享内存原语相比，它的性能良好，原因相似。 这导致了一个简单的架构，允许GRAM扩展。 为扩大规模，GRAM使用特别设计的基于RDMA的网络通信栈，该网络通信栈（i）能够在不同服务器上的线程对之间进行基本上并发的数据传输，（ii）平衡多个核心上的协调负载并应对由于NUMA引起的异构性，以及（iii）使通信与计算重叠，并根据通信和计算的比例自适应地调整复杂粒度。下面详细介绍设计
4.Multicore-Aware Communication Stack with RDMA
为扩大规模，GRAM有一个专门设计的通信堆栈，它（i）考虑到服务器的多核架构，旨在以平衡的方式保持CPU core并行性，并且（ii）利用数据中心可用的RDMA， 因为融合以太网上的RDMA（RoCE）[17]等技术。 RDMA Queue Pair提供可靠的连接，其中已注册的远程内存区域的请求直接发送到NIC而不涉及内核，并且由远程NIC处理而不涉及远程CPU。 GRAM建立在使用RDMAWrite的FaRM消息传递机制[12]上：n RPC发送者通过单向消息传递通道将数据传输给接收方，接收方或接收缓冲区中有一个专用的循环缓冲区。RPC发送程序使用RDMA writes直接将数据传送到（远程）接收缓冲区。GRAM不使用FaRM中的共享内存原语，基于与服务器内部情况相同的原则。因为对于图计算工作负载来说，对于一些小的随机访问的数据传输使用批量发送消息传递的原语，这是一种更加有效的方法。相反，FaRM的驱动场景是支持查询和(事务)更新的存储抽象，其中主要关注的是单个请求的延迟，而不是GRAM所针对的并行计算工作负载。这一设计选择也为GRAM建立了统一的比例模型。
4.1 Overlapping communication and computation
对于图计算，RDMA的主要优势来自于重叠通信和计算以隐藏通信延迟的机会，因为CPU不再参与基于RDMA的通信。 因此，GRAM的设计目标是允许所有CPU core在图计算任务上并发同时执行，并让通信与计算重叠。这自然会导致一个对称的线程模型，它将线程引导到硬件CPU core，如FaRM。 每个线程都以事件驱动样式编程，以执行图计算工作并轮询基于RDMA的通信。
计算包括枚举顶点和边数组以处理顶点数据，准备和填充发送缓冲区以将数据传播到远程服务器上的邻居，并处理来自远程服务器的接收缓冲区中的数据。实际上，GRAM用于枚举图形数据和发送消息的本地计算任务的最大片数为100μs，而处理接收到的消息的任务的弹性时间片可能更大。实际上，GRAM用于枚举图形数据和发送消息的本地计算任务的最大片数为100μs，而处理接收到的消息的任务的弹性时间片可能更大。此设置的目的是在必要时优先处理消息消耗任务（以防止发送缓冲区中的过多消息队列），同时在计算和通信之间提供平衡。我们的经验表明，GRAM的性能对调度设置不是特别敏感，我们还没有发现需要实现更复杂的调度机制。
重叠的通信和计算使得GRAM可以大规模的扩展集群，尽管与服务器内部通信和内存带宽相比，跨服务器通信的成本更高并且吞吐量更低。如第5节所示，我们观察在多个服务器上运行的多个GRAM worker的性能与在一台相同服务器的多个CPU core上运行相同的GRAM worker的性能一样。
4.2 NUMA-awareness and balanced multiplexing
因为许多图计算算法使用跨迭代的Barrier机制，所以让所有线程在大约相同的时间内完成每个迭代对于系统性能非常重要。也是为什么GRAM是从对称线程模型开始的。为了处理由于NUMA导致的现有异构性，所有GRAM的数据和缓冲区分配都是与NUMA相关的，最小化线程数据或者buffer访问在不同的NUMA节点下。对于图数据，GRAM保证线程拥有的图分区从与线程专用的core相同的NUMA节点上分配。
通信堆栈还必须保持跨线程的对称性。GRAM的RPC抽象是在线程的粒度上，一个线程与每个远程线程都有一个单独的RPC连接。一个幼稚的实现会为每对线程对分配一个接收缓冲区，因此每个服务器需要O（M2×N）个缓冲区，其中N是服务器数量，M是每个服务器的CPU核的数量。随着系统中服务器数量的增加，接收缓冲区的总数很快成为缩放的限制因素。 （每个服务器每个接收器缓冲区为64MB和16个CPU 核，每个线程/core具有一个接收器缓冲区，每个服务器需要1TB的64个服务器设置。）因此接收器缓冲区在GRAM中被复用。一个专有的接收buffer缓冲区将发送线程和接收线程中连接。我们始终确保接收器缓冲区与接收线程位于同一个NUMA节点上，因为那些接收线程将访问缓冲区。为了确保接收缓冲区和管道被复用，GRAM将服务器中多个工作线程进行分组，每个分组中的多个工作线程共用Channel和接收缓冲区。为了确保复用并减少争用，在发送方和接收方都引入了一个协调器。发送方的协调器保持接收缓冲区的尾部。当一个线程想要发送一条消息时，它会要求协调器保留发送消息的接收缓冲区。协调器会相应地更新尾部地址，以防止其他线程写入重叠的地址空间。接收端的协调器轮询接收缓冲区。当有新消息时，它会查看消息的Header，以确定该消息适用于哪个线程。然后通知相应的线程，相应的工作现场根据缓冲区中消息的偏移量和大小直接从接收缓冲区读取消息。消息完成后，线程通知协调器接收器缓冲区中的缓冲区可以重新使用。
协调员的责任被分配到一个核心。 我们的经验表明，由于内核协调负载不均衡，协调器对内核的不均匀分布会对GRAM的性能产生不利影响。 在GRAM中，我们始终对系统进行配置，以便协调者大致均匀分布在各个线程中：服务器上的每个线程组（Group）中有多个通道，因此有多个协调器，因为服务器与相对应服务器上的多个其他组进行通信。 在服务器数量远小于每台服务器上的内核数量的配置中，GRAM会为每个组创建适当数量的组和足够数量的通道，以实现近似均匀的分配。
图3示出两个服务器（服务器1和2）与服务器0通信的情况。每个服务器具有两个组（例如，NUMA节点内的线程可以形成组）。每个组建立一个通道到相应的远程服务器组，组内的线程共享相同的通道。
NUMA-awareness：
1. 对于图数据，GRAM保证线程拥有的图分区从与线程专用的core相同的NUMA节点上分配。
2.我们始终确保接收器缓冲区与接收线程位于同一个NUMA节点上，因为那些接收线程将访问缓冲区。
4.3 Trade-off between parallelism and efficiency
GRAM的设计特别关注通信堆栈中的高并行性。例如，线程为每个远程线程维护一个发送缓冲区，因为RPC提供了线程粒度抽象：在这种配置中，RPC接收方不需要额外的协调或解复用，每个接收线程独立地处理在接收缓冲区中发送给它的消息，从而最大限度地提高并行性。当有足够的并行计算可以保持所有CPU 核繁忙时，这样的每一个对等线程发送器缓冲器设计效果最佳，同时隐藏了通信成本。这并非总是如此; 例如，某些图计算的某些阶段不涉及图中的所有顶点，或者当集群规模很大，并且图分区到分区上的计算不再足以掩蔽通信成本。我们的评估表明，每个RPC调用都有不可忽略的开销，用于准备缓冲区，调用通信堆栈并在网络上传输。因此发送许多小的小消息是昂贵且低效的。为了获得高通信效率，需要512KB的批量大小。 GRAM最初的设计基本上支持并行性而不是批量发送，在这种设置中不再适用。因此，我们引入了一种不同的设置，通过将一个线程的所有发送方缓冲区合并到同一远程服务器上的所有线程(例如:，一个对等服务器的缓冲区安排)。在这个方案中，RPC是在粗粒度的情况下进行的，以更好的批量发送消息。合并的缓冲区被发送到远程服务器中的一个委托线程，该线程通过线程消息传递将消息分解多路分发给适当的线程。这将引入额外的开销，但是我们的评估表明，当集群规模较大时，这种权衡是有效的。
为了在所有情况下获得更好的性能，GRAM采用了一种简单的策略，在图计算中自适应地切换两种方案。当语法观察到在非重叠通信上花费的时间超过阈值时，它将在下一个迭代中切换到每个对等服务器缓冲方案，反之亦然。
5.Evaluation
GRAM实现约6000行C ++代码。在本节中，我们将提供详细的评估结果来支持我们的设计选择，并展示GRAM的效率和可扩展性，以及与其他最先进的引擎（如Naiad [27]和GraphX [14]）的对比。
Expermient Setup
我们在商品多核服务器集群上评估GRAM。 每台服务器在双2.6 GHz英特尔至强E5-2650处理器（16个物理内核和32个逻辑内核）上运行Windows Server 2012 R2，256GB内存和一个带54Gbps带宽的MellanoxConnectX-3 InfiniBand NIC。
我们的评估是在6个图表数据集上使用3个图表应用程序，PageRank，弱连接组件（WCC）和单源最短路径（SSSP）执行的。我们在所有PageRank实验中运行5次迭代。表1按图表大小的升序列出了图表数据集。 “Edge大小”列显示相应图形中边缘列表的内存占用量。存储边缘信息的数据结构通常在图形引擎中占据内存足迹。前5个图是公共可用的实际社交或网络图，范围从15亿边缘到128亿边缘。请注意，原始uk-union图有55亿条边。为了使图形比uk-2007-05大得多，我们使所有的边都是双向的。最后一个和最大的图是具有1.2个三角形边的合成图，其中每个顶点的度由1到281的随机数设置，并且来自顶点的每个边随机地连接到任何剩余的顶点。据我们所知，这是迄今为止分布式内存中图形引擎处理的最大图形[10]。除非另有说明，否则所有图都是随机分区的。
本节的其余部分回答以下问题：
1）跨线程消息传递对于改善多核服务器上的图计算性能与共享内存原语相比有多有效？
2）基于RDMA的GRAM网络通信堆栈的性能如何，特别是在计算和通信重叠，平衡复用以及并行性和通信效率之间的权衡方面？
3）在GRAM中缩放的COST [25]是什么，它与一个有效的单线程图算法实现相比如何？
4）GRAM的性能与现有的最先进的替代系统相比如何？
5）GRAM在万亿次边缘图上表现如何？
5.1 Inter-thread message passing vs. shared memory
在这组实验中，我们验证了GRAM选择使用通过共享内存原语的消息传递，甚至对于服务器内的内核间通信也是如此。 对于消息传递，批量发送消息一个重要因素，我们研究消息批量大小在实验中如何影响性能。 对于共享内存原语，我们检查两个原语：一个使用Lock来保护图数据竞争，另一个使用原子指令集来更新图形数据。 图4（a）和4（b）比较了单个服务器（32线程配置）下的PageRank（一次迭代）和WCC在Twitter图表上的性能（以秒为单位）的运行时间（以秒为单位）：消息传递 不同的批量大小（Msg），带锁定的共享内存（Lock）以及带有原子操作（Atomic）的共享内存。
结果表明，使线程间消息传递效益最大化的最佳消息批量大小约为2K〜8K字节，远大于高速缓存行大小。这是为了摊销归因于每个消息传递的持续开销; 例如，消息缓冲区的分配，对消息队列的操作等等。很大的批量发送消息大小将开始影响消息传递延迟。 对于PageRank而言，通过使用线程消息传递（3.7秒），与具有Lock（8.9秒）的共享内存相比，GRAMachie拥有最佳批处理大小（2KB），与共享内存相比，其性能提高了约90％ 与原子指令（7.1秒）。
对于WCC，相对于Lock的性能改进在2KB批量大小时约为100％，这比PageRank的性能增益要低。 这是因为WCC每个顶点的更新次数少于PageRank（在WCC中，如果传播的组件ID大于目标顶点的传播值，传播的值将被丢弃）。 我们观察到其他图形数据集的相似结果
我们用了。 对于uk-union图表上的PageRank，具有最佳批处理大小的消息传递与Lock相比提高了100％，Atomic提高了46％。对于WCC，相应的改进分别是50％和34％。
5.2 Efficient RDMA Communication for Scaling Out
一个高效的基于RDMA的通信栈是GRAM性能和可扩展性的关键。我们设计了一系列实验来评估通信栈的不同方面。 首先，我们研究通信计算重叠的影响以及GRAM如何实现这一点。 由于这种重叠，我们表明GRAM可以扩大规模，尽管扩大规模的通信成本要高得多。 然后，我们通过调查协调者分配和具有NUMA意识来调查平衡的重要性。 我们进一步研究了GRAM中的不同配置，通过调整通信堆栈中复用的大小来平衡并行性和通信效率。最后，我们比较一个基于RDMA的网络堆栈和TCP。 我们仅在u-union图上显示评估结果。我们在其他图上观察到类似的结果。
Overlappingcommunication and computation.
GRAM效率的一个重要来源来自与RDMA计算的重叠通信。我们研究了GRAM如何管理重叠通信与各种配置的计算。图5显示了在具有不同数量的服务器的uk-union图上运行PageRank时，通信的计算和可观察的非重叠部分的细分。 x轴是全局分配给所有服务器上所有线程的工作者ID，服务器0上的工作人员0〜31，服务器1上的工作人员32〜63等等。 y轴是一个PageRank迭代的执行时间，以毫秒为单位。我们将执行时间分为两个阶段：计算阶段和非重叠通信阶段。在计算阶段，如深蓝色条所示，工作人员枚举顶点和边，准备要传播给邻居的数据，并处理从其他工作人员收到的消息。这个阶段的通信部分与计算重叠。浅黄色条表示工人在工作阶段之后的非重叠通信阶段。这一阶段的操作包括将剩余的消息放入缓冲区并接收其他工作人员发送的消息（如果有剩余的话）。
图5（a）显示了8台服务器上的图形计算几乎完全掩盖了通信。淡黄色的条纹几乎不可见，这意味着通信在计算后立即完成。但是，这种理想的重叠并不总是能够实现的，特别是当工作人员所拥有的图形分区的大小太小时：由于碎片化导致的数据通信变得效率低下，并且没有足够的计算来隐藏通信成本。图5（b）显示了这种情况。使用64台服务器时，通信阶段占用的总时间要比8服务器案例中的占很大的一部分。计算和通信之间的次优重叠解释了为什么性能加速从8服务器到64服务器是次线性的。如图5（a）所示，在uk-union上计算PageRank的一次迭代在8台服务器上花费的时间略多于5秒。假设线性缩放，它将在64个服务器上减少到大约0.625秒。而实际值仅为1.2秒，如图5（b）所示。当计算时间落入亚秒时，通信可能变得太碎片化，因此很难利用批量发送消息，这导致重叠和整体性能更差。
Scale-out vs. scale-up.
重叠的通信和计算使得GRAM可以像扩展一样有效地扩展，如以下实验令人惊讶的结果所示。 在这个实验中，我们检查两个配置。 在纵向扩展配置中，我们使用单个服务器，每个工作线程专用于一个逻辑核心。 所有的线程间通信都在服务器内。 在横向扩展配置中，我们将每个工作线程放置在专用服务器上，并将工作人员关联到单个核心。 因此，所有线程间通信都通过RDMA网络跨服务器进行。
图6显示了这两种配置之间的比较。 如图所示，由于减少了RDMA中的CPU参与以及通信和计算的重叠，因此GRAM在扩展配置中的性能与放大配置中的性能几乎没有区别。 请注意，在32位工作者情况下，向外扩展配置中的性能甚至优于扩展配置中的性能。 这是因为单个服务器上只有16个内核，并且使用超线程来支持32个线程。
Balanced coordinatorassignment. Balanced
平衡并行性对于使用迭代之间的Barrier的图计算很重要。 GRAM的设计小心地将协调器分配给核心以实现这种平衡，如4.2节所述。图7（a）详细显示了不平衡协调员分配如何影响整体绩效。在这个实验中，我们使用4台服务器在uk-union图上运行PageRank。如图5所示，我们在所有4台服务器上显示每个线程（共32×4）的行为，并将执行时间分为两个阶段：计算和Barrier，其中Barrier阶段是指工人花费在屏障上等待。在这种配置中，有3个发送者/接收者通道，每个服务器上的前三个线程充当协调者：协调者的工作者ID是0〜2,32〜34,64〜66和96〜98，分别。如图所示，担任协调员的工作人员在计算阶段花费的时间比其他人长，而其他进入障碍阶段的工作人员则要等待这些工作人员。为了缓解这个问题，我们在每个服务器中引入8个组，每组3个发送者/接收者通道。然后每个服务器有24个发送者/接收者协调器分布在32个核心中。这大致平衡了负载。 我们的实验表明，通过这种方式减轻协调员不平衡可以将整体绩效提高33％。
NUMA awareness.
另一个不平衡的来源可以通过NUMA不可知的数据分配来引入。 图7（b）显示了这个问题的影响。 在这个实验中，所有数据（包括图形数据和RPC缓冲区）都是从NUMA节点0的内存中分配的。结果清楚地表明NUMA节点0中的所有工作人员在计算阶段执行的速度都快于NUMA节点1中的所有工作人员， 内存更接近NUMA节点0中的CPU内核。图8显示了将NUMA感知应用于不同数据部分的性能增益细分。 它表明，将NUMA感知应用于图形数据和RPC缓冲区时，GRAM实现了40.9％的性能增益。
Trade-off between parallelismand efficiency
如第4节所述，并行性和通信效率之间存在内在的Trade-off。 通过在两个发送缓冲区安排方案之间进行自适应切换，GRAM探索了不同配置之间权衡的不同点：1）每个对等线程有一个发送缓冲区; 2）每个对等服务器有一个发送缓冲区。 后者需要一个额外的调度阶段来将消息传递到其目标线程，但由于在同一台服务器上接收线程的批量发送消息而获得效率。
图9显示了具有不同数量的服务器和不同图形应用程序的两种方案的性能比较。首先，当所使用的服务器数量很少时，每个对等线程缓冲区布置（表示为无调度）的性能会更好，因为在计算成本占主导地位的有效配置中有利于并行性是正确的选择，并且可以在并行性的水平。当服务器数量增加到8个或更多时，每个线程的计算量减少，线程之间交换的消息相对变少（线程的数量增加），从而导致网络效率降低。在这些情况下，支持通信效率的每对等服务器缓冲区方案（表示为分派）开始表现出色，因为它将消息分批发送到同一远程服务器的所有线程。批量发送消息的好处超过了将消息重新分配给目标线程的额外开销。只有少量的服务器，这种调度开销显而易见（与不分配相比，性能下降高达21％）。
在64台服务器的情况下，调度方案分别实现PageRank和WCC的3.7倍和3.9倍性能改进。 请注意，WCC通常更多地受到碎片问题的困扰，因为在WCC中，在大多数迭代中只有一小部分顶点在计算中处于活动状态，从而更多地受益于合并的缓冲区布置（即调度）。
RDMA vs. TCP/IP.
通过与配置为使用TCP / IP的GRAM版本进行比较，我们进一步显示了由于RDMA而带来的效率增益。 为了使TCP在高带宽网络中的吞吐量最大化，我们调整TCP窗口大小以使其成为实验的最佳选择。 图10比较了uk-union图表上的PageRank与RDMA和TCP通信堆栈的性能。 使用RDMA的GRAM始终比使用TCP的GRAM执行3倍。 TCP堆栈的性能下降来自于繁重的TCP / IP内核堆栈的重大开销，包括用户模式和内核模式之间的切换，复杂的多层协议，内核数据结构上的锁争用，不可避免的消息数据复制以及缺少 灵活应用NUMA感知优化。
5.3 Cost analysis
如果一个系统的单线程实现成本很高，那么系统可能会扩展到多个服务器。 最近的一项研究表明，一些分布式系统确实以高成本进行扩展[25]，并提出了一种新的度量COST（或者性能优于单线程的配置）来评估系统的效率。 更准确地说，如果图形引擎需要C核超过同一图算法的单线程实现，那么图形引擎的代价为C.我们现在报告GRAM的成本，分析比单线程专用实现更多的额外开销 并演示证明，开销主要是作为通用分布式平台的结果。
对于我们的COST分析，我们将GRAM与优化的单线程PageRank实现的公共版本进行比较[25]。因为最初的实现是用C＃实现的，而GRAM是用C ++实现的，所以我们将C＃版本移植到C ++实现中以消除语言运行时的潜在开销。运行单线程实现时，我们将线程关联到专用核心。在twitter图上，C＃实现需要15.5秒，我们的C ++版本需要14.5秒1，这相当接近。相比之下，GRAM的单线程性能为20.3秒。我们进一步分析造成绩效差异的来源。事实证明，主要来源与我们的意图有关，使GRAM成为通用平台。在这里，我们强调主要的。第一种类型的开销来自检查顶点状态的代价。对于一些图算法，引擎需要检查一个顶点的状态在前一次迭代中是否发生了变化。该检查有助于确定算法执行何时收敛并可以终止。诸如PageRank，WCC和SSSP等算法都需要进行这种状态检查来完成一个完整的计算过程。但是，单线程的PageRank实现只是执行固定次数的迭代，没有任何逻辑来检查顶点状态。由于添加了这些检查，图11中的“状态检查”栏显示与优化的单线程实施（“优化”栏）相比减缓了4.1％。
第二个平台开销来自调度开销。为了重叠计算和通信，GRAM中的每个工作人员都必须定期生成计算，并执行一些通信任务来轮询和接收消息。 这引入了一些必要的上下文切换成本。 图11中的“ContextSwitch”栏显示了这种性能开销。随着收益，性能下降到18.4秒，这相当于额外开销的21.9％。
最后，作为一个平台，GRAM引入了一些必要的分支成本，例如，找出数据应该传播到哪个分区。 “GRAM”栏包含这种开销。 请注意，GRAM在模板函数中提供了Gather-Apply-Scatter图形接口[13]，因此可以通过编译器实现有效内联，以避免应用于每个边时接口调用的开销。
我们的调查还揭示了影响图形引擎性能的其他因素。我们最初进行细粒度图分区以便于负载均衡。 我们观察到，过多的分区可能会对性能产生不利影响。 在我们的实验中，我们将Twitter图划分为32个分区，并在32个分区上运行单线程GRAM。 执行时间从20.3秒增加到42秒。 这是因为随机分区使图形布局的局部性恶化，如[25,32]中所观察到的。 此外，系统还引入了额外的分支，以允许单个工作人员处理多个分区。
在了解单线程性能之后，我们进一步展示了GRAM的可扩展性以便计算其成本。 图12显示了GRAM在多核服务器上的性能提升。 4核心的GRAM的性能优于优化后的单线程实现，因此COST为4.如图所示，从1核心到2核心的加速比较小，主要是由于额外的平台开销支持并发通信 - 租用核心消息传递的工作线程。我们看到从2核到16核的近乎完美的缩放比例。 性能继续提高到32核，但由于超线程技术，性能仅略有提高。
6. Discussion
虽然GRAM的设计侧重于利用RDMA的优化，但我们的经验揭示了对其他通用可扩展分布式计算引擎的设计人员可能有价值的原理和经验。
首先，GRAM的设计显示了在计算和通信之间取得平衡的重要性，这对于分布式计算引擎的效率和可扩展性而言通常是关键的。虽然系统可以通过分区和并行化来增加核心（服务器）以加速计算，但系统的可扩展性受以下几个因素的限制：（i）当顶点数量增加时，通信成本和开销增加; （ii）由于批量发送消息机会减少导致通信效率下降，以及（iii）计算不足以重叠和掩盖通信。正如数据库系统旨在隐藏磁盘延迟一样，重叠的通信和计算对于RDMA和其他绕过内核的消息传递原语特别有效和重要。如何管理通信成本，保持通信效率，平衡通信和计算成为共同的主题。正如我们在GRAM中观察到的图形计算一样，通信和计算之间的平衡通常依赖于工作负载和动态，因为系统执行时平衡发生了变化，因此需要采用自适应策略。
其次，传统观点认为网络成本在分布式系统中占主导地位。 我们使用GRAM的经验表明，即使对于分布式计算引擎，本地计算效率和多核并行性也很重要。 仔细的设计考虑到地区，NUMA意识和平衡并列等问题，最终会产生巨大差异。 一个好的设计可以并且应该同时实现效率（针对高度优化的单线程实现）和可伸缩性。
第三，当与其他分布式计算引擎进行比较时，我们也意识到编程语言的选择具有微妙但有时是重要的意义，尤其与RDMA有关。 例如，用于高级语言（如Java和C＃）的托管运行时可能会对线程模型和内存管理施加约束。GRAM采用FaRM基于轮询的线程模型，其中线程专用于核心轮询RDMA消息，而托管运行时往往具有诸如垃圾收集之类的后台线程，这会降低并行性。 另外，由RDMA网卡访问的内存区域必须是不可分页的，因此在网络数据传输期间不允许交换。 这可能与具有自动内存管理的托管运行时的内存模型不一致。
7. Relate Work
并行或分布式图形处理系统的研究和开发最近受到图形数据的规模和重要性的推动。一些图形系统[21,30,32,33,36]专注于单服务器优化以扩展多核服务器上的图形计算，而其他图形系统[8,9,13,14,23,24,27,31,34]强调扩展服务器集群以更大规模地利用并行性。 显示Chaos[34]能够在32台服务器上在两天内处理1万亿的边缘图，因为它提供了二级存储的横向扩展解决方案，这是与GRAM有趣的不同设计点。
即使在单服务器的情况下，GRAM也拥有消息传递的更高性能。 Barrelfish [3]提倡在操作系统场景中进行类似的设计，而我们证明了消息传递的好处以及批量处理graphworkloads的重要性。 Grappa [28]通过将共享内存抽象转换为底层消息传递执行来实现这一想法。
最近的一项研究[25]表明，许多分布式图形处理系统的规模都很大，但与同一图形算法的单线程实现相比，成本很高。 一些已发布的系统要么需要大量的内核才能胜过单线程实现，要么永远无法与其性能相匹配。 因此，GRAM不仅报告可扩展性，还报告它在COST方面的效率。 综合效率和可扩展性使得GRAM可以处理具有超过1万亿条边的大图，并且在我们的实验中大幅超越现有图形引擎。
鉴于RDMA带来的低延迟和高带宽，一些工作[18,26]探索了key-value 存储的机会，而另一些人[12,28]重新讨论并主张分布式共享存储器抽象。 相比之下，图形计算的特性导致了GRAM中的不同选择，平衡并行性，计算和通信的重叠以及网络效率/吞吐量比绝对延迟更重要。
单服务器图形引擎中使用的一些优化技术是对GRAM的补充。 Grace [32]提出了一种技术，通过图形感知数据布局来利用图形工作负载的更好的数据局部性，这种布局可以很容易地集成以提高GRAM的效率。 Galois [30]扩展了顶点程序接口，允许应用程序指定优先级，并采用基于优先级的调度，为可从中受益的工作负载（例如WCC）提供可伸缩的优先级队列。他们的技术可能不容易直接扩展到分布式设置，但GRAM采用优先级接口并为每个线程使用优先级队列来为这些工作负载获得类似的优势。聚合物[39]为单服务器设置提出了NUMA感知图数据布局和调度策略，而GRAM的网络堆栈也设计为NUMA感知。 GRAM的系统设计并不妨碍一些分布式设置的补充技术的集成，例如Surfer [7]，PowerGraph [13]和PowerLyra [8]中使用的图分区方案。针对巨大图的高级分区方案是一项艰巨的任务，而由于有效的RDMA通信栈，GRAM通过简单的哈希分区来演示其效率。还有另一种以图表系统研究为目标的在线图表查询方案[2,11,29,35]。探索RDMA如何使这种系统受益将会很有趣。
8. Conclusion
越来越需要有效地处理越来越大的图形，以从关系和连接的图形结构中提取有价值的见解。 通过GRAM，我们证明了一种高效且可扩展的图形引擎，能够处理超过一万亿条边的图形，并且可以利用多核和RDMA等新硬件功能的原则设计。 我们的详细评估进一步验证了关键设计选择，并阐明了扩展分布式计算引擎的关键。