论文阅读 Docker Container Scheduler for I/O Intensive Applications Running on NVMe SSDs

Abstract

通过使用快速后端存储，可以通过快速I/O响应来利用轻量级容器平台的性能优势。然而，同时执行相同或不同应用程序的多个实例的性能可能会随着容器的数量而发生显著变化。由于不同的应用程序在ssd上的I/O类型(读/写)、I/O访问模式(随机/顺序)、I/O大小等方面表现出不同的性质，因此性能也可能因应用程序的性质而异。因此，本文的目的是研究和分析I/O密集型Docker应用中均质和非均质混合物的性能表征，使用高性能的NVMe固态硬盘，并得出新的设计准则，以实现均质和非均质混合物的最佳和公平操作。通过利用这些设计指南，我们进一步开发了一个新的docker控制器，用于调度不同类型应用程序的工作负载容器。我们的控制器决定同时操作容器的最佳批次，以最小化总执行时间和最大化资源利用率。同时，我们的控制器还努力平衡所有同时运行的应用程序之间的吞吐量。我们开发了这个新的docker控制器，通过解决一个优化问题，使用五个不同的优化解决方案。我们在三个企业NVMe驱动器阵列上运行的多个docker容器平台上进行实验。我们使用不同I/O行为的不同应用程序进一步评估我们的控制器，并将其与不使用控制器的容器的同步操作进行比较。我们的评估结果显示，新的docker工作负载控制器有助于加速ssd上多个应用程序的整体执行。

1 INTRODUCTION

DOCKER容器由于其简单、高效的操作特性[1]而受到越来越多的关注。容器技术将成为缩短软件开发周期[2]、[3]、[4]的主干。容器和虚拟机具有类似的资源隔离和分配优势，但是不同的体系结构方法使容器比虚拟机[5][6]更具有可移植性和效率。在各种容器技术(如docker、LxC、runC)中，docker由于其易于部署和可扩展性而成为主流技术之一。
容器与虚拟机。虚拟机(VM)和docker容器这两种虚拟化技术各有其特点和优点。了解它们的特性和局限性可以帮助我们改进在这些虚拟化环境中运行的应用程序的性能。

docker的最新进展不同于传统的vm。首先，VM管理程序以分布式模式管理不同虚拟机之间的资源，其中每个VM都被分配了它可以使用的最大资源限制。与VM不同，容器化虚拟化在不同容器之间执行集中的资源管理。诸如处理单元、内存和页面缓存等资源在所有容器之间共享。不需要预先分配资源，所有容器在运行时都要争夺共享资源。因此，在使用Docker容器时，资源争用和性能干扰比使用vm时更加严重。因此，在Docker容器环境中，通过有效的调度算法来启动Docker容器来缓解这种性能干扰，提高资源的利用率就显得更加迫切和必要。其次，每个VM都有自己的VM映像，由来宾操作系统和库组成。这种类型的虚拟化带来了更好的安全性和隔离性，但是会导致更高的启动开销。因此，一种临时的做法是在开始时启动所有vm。另一方面，由于Docker容器是轻量级的，没有来宾操作系统，因此可以在需要时启动它们。因此，这给了我们一个很好的机会来动态调度并在运行时启动Docker容器。

使用NVMe ssd的容器化数据库。虽然在裸金属或虚拟机上表征应用程序的性能不是新的[7]、[8]，但I/O密集的dockerized应用程序值得特别关注。首先，docker容器的轻量级特性促进了同时使用多个容器来部署相同或不同应用程序[9]的多个实例。其次，随着容器化实例数量的增加，资源的保有量也随之增加，从而导致每个实例的性能发生变化。然而，不同应用程序的并发实例的行为还没有得到彻底的研究。第三，随着世界对高性能ssd(如非易失性内存快车(NVMe)设备)的期待，由于其巨大的存储需求，使用这些NVMe ssd作为后端，可以在I/O密集型dockerized应用程序上获得更多的性能优势。鉴于目前的技术水平，我们迫切需要更好地了解NVMe高端ssd中不同类型工作负载和应用程序的性能。

Performance Characterization（性能表征）。我们将应用层设置分为同构和异构。具有相同工作负载特征的单个数据库应用程序的保留实例称为同构，因为所有此类容器都将竞争类似的资源。举个例子，如果所有的容器都是运行TPC-C的MySQL，那么这个设置就叫做同构。而具有不同工作负载的不同数据库应用程序的容器实例称为异构。例如，如果一些容器是MySQL运行的TPC- C，而同时另一些容器是Cassandra运行的Cassandra-stress，则该设置称为异构。我们注意到上面的例子是为了投射应用程序的同构和异构混合的一般类的思想。在这篇论文中，我们首先描述了docker容器在NVMe固态硬盘上的操作，考虑了同时操作容器的数量和应用。我们观察到，对于一个同构的环境，随着容器数量的增加，性能可能会得到改善，但最终可能会由于硬件资源的限制而达到饱和甚至更糟的性能下降。对于异构环境，我们观察到一些应用程序的吞吐量在与其他应用程序同时运行时显著降低。

Docker Workload Controller。Docker容器是一组进程，它们属于Linux名称空间和控制组(cgroups)的组合。使用cgroups[10]管理容器之间的资源有助于优先化实例并实现隔离。资源共享是集装箱技术的主要特点。默认情况下，容器没有资源使用约束，因此，如果需要，可以在主机内核调度器允许的范围内尽可能多地使用(和共享)资源。Cgroups提供了控制容器可以使用的每个资源(例如，内存、CPU或块IO)的部分的方法。然而，设置这种固定的资源使用限制实际上限制了在线资源共享和整体资源利用。因此，在这项工作中，我们提出了一个docker容器调度器，它能够利用资源共享来最大限度地利用资源，并通过确定哪些容器应该在同一批中同时操作来避免应用程序干扰。
为了提高性能，我们构建了一个docker工作负载控制器来调度同时运行的几批容器的执行。我们将这个优化问题建模成一个数学目标函数及其约束。我们用五种不同的优化解算器对控制器进行了评估，并与不使用控制器的容器同时运行时的性能结果进行了比较。我们的实验结果表明，我们新的docker工作负载控制程序有助于加速ssd上多个应用程序的整体执行。
在本文中，我们的目标是探讨不同的实际集装箱数据库应用程序的行为与高性能NVMe固态硬盘，并开发一个控制器，以自动化调度不同集装箱的操作。本文的主要贡献总结如下:

• 了解同质新应用程序设置的写和读密集型容器工作负载的性能。
• 分析和改进不同应用程序容器之间的资源利用和资源公平共享。
• 研究不同应用程序容器的同时操作的应用程序吞吐量节流。
• 为高性能NVMe固态硬盘混合码分多址系统的优化和公平运行提出了新的设计准则。
• 基于派生的指导原则开发docker工作负载控制器，以最小化总体吞吐量、最大化资源利用率和最小化应用程序干扰，从而加速同时运行应用程序容器的整体操作。

本文的其余部分组织如下。在第二部分，我们描述了相关的工作。第三部分介绍了docker容器的数据存储和实验设置。在第4节中，我们将讨论同构docker容器和异构docker容器。在第5部分中，我们将结果总结为指导方针，在第6部分中，我们开发了一个新的控制器，以便基于派生的指导方针对工作负载容器进行分组。最后，在第七部分得出结论并对今后的工作进行了讨论。

2 RELATED WORK

大多数数据库应用程序(如Redis、MySQL等)的docker容器都可以下载[1]。据报道，在虚拟机上使用docker容器提高了性能，这在很短的时间内就吸引了许多用户。Charles Anderson介绍了docker[2]作为容器虚拟化技术，它与虚拟机相比非常轻。Docker容器正在成为当前在公共和私有云中部署应用程序的主流机制[11]、[12]、[13]。

另一方面，为了在应用层支持多个数据库应用程序容器同时运行的并行数据密集型应用程序，需要非常快的存储。ssd最初用作缓冲池，用于在RAM和硬盘[14]、[15]、[16]、[17]、[18]之间缓存数据。但是，随着闪存驱动器的$/GB不断减少，ssd作为主存储器的使用变得显著的[19]，[20]。目前，ssd在企业服务器和数据中心中的使用越来越多。在[21]和[22]中，作者探讨了ssd作为数据库应用程序的主存储器。利用固态硬盘[23]、[24]、[25]、[26]提高数据库应用程序的能源效率，也进行了广泛的研究。此外，随着世界对高性能ssd的巨大存储需求的期待，NVMe正在成为通过PCIe[27]与高性能ssd通信的协议。

传统集群(如Mapreduce Hadoop)的设计主要关注于运行大量作业，但容器集群通常用于运行几十个小实例，需要组织这些实例来优化数据存储和计算能力。因此，传统的VM调度器，如Apache YARN[28]和ZooKeeper[29]，如果直接应用到docker容器上，效率不高。另一方面，现有的容器调度技术，如Docker Swarm[30]和Mesos[31]，在单一主机上无法控制不同容器的启动时间。此外，目前的集装箱调度方法都是以资源利用率最大化为目标的。然而，我们发现这些方法实际上受到了应用程序性能干扰，因为在多个容器之间共享操作系统资源。

我们研究了已知优化问题的文献，如bin packing[32]、[33]、[34]、[35]、背包[36]、作业调度[37]、[38]、[39]的不同变体，没有找到一个好的解决方案可以直接应用到我们的问题。因此，在这项工作中，我们开发了一个解决方案的变化的经典装箱问题与不同的问题约束和干扰刑罚。据我们所知，这是第一次尝试研究这样的控制器在dockerized应用系统中的性能。在本文中，我们的目标是探讨不同的实际集装箱数据库应用程序的行为与高性能的NVMe ssd和开发一个控制器，以自动调度不同的container的操作。

3 HARDWARE ARCHITECTURE AND APPLICATION LAYOUT

3.1 Container Data Storage

Docker使用容器化环境提供应用程序虚拟化。Docker映像是一个惰性的、不可变的文件，本质上是容器的快照。可以用应用程序映像实例化多个docker容器。为了保持轻量级特性，建议将容器内的安装堆栈尽可能小以获得更好的性能。容器的数据管理由docker存储驱动程序(例如，OverlayFS、AUFS、Btrfs等)或docker数据卷进行监督。

Docker守护进程只能运行一个存储驱动程序，由该守护进程实例创建的所有容器都使用相同的存储驱动程序。存储驱动程序使用的是写时拷贝(CoW)技术。CoW的基本思想是，如果多个调用者请求最初无法区分的资源，那么可以返回指向相同资源的指针。可以维护此函数，直到调用者试图修改其资源的“副本”，此时将创建一个真正的副本。对于生成大量写工作负载的应用程序，CoW是没有用的。因此，对于写密集型应用程序，建议维护数据的持久副本。Docker卷是一种为容器自动提供数据持久性的机制。卷是可以直接挂载在容器内的目录或文件。这个特性的最大好处是，通过这个路径的I/O操作独立于存储驱动程序的选择，并且应该能够在主机的I/O能力下操作。

在本文中，我们使用docker数据卷的持久存储选项来描述I/O密集型应用程序的性能。图1显示了底层硬件的堆叠I/O路径。如图1f所示，I/O请求是由容器化的工作负载生成的。数据卷是一个或多个绕过docker文件系统的包含程序中专门指定的目录。主机上的I/Os可以由主机支持文件系统(如XFS或EXT4)来管理(参见图1e)。在所有实验中，我们都使用XFS作为备份文件系统。这个备份文件系统依赖于逻辑卷和物理卷的堆栈。这些逻辑卷和物理卷是在一组NVMe ssd上构造的，参见图1a、1c和1d。

3.2 Experimental Setup

我们建立了一个平台组成的多个docker containers操作在三个企业NVMe组成数组的驱动器(3 tb)上，为了提供更高的磁盘带宽,如图1所示的堆栈主机操作系统,docker engine和docker应用镜像保持一个单独的磁盘上,不同于一个用于存储集装箱应用-阳离子文件和数据库(参见图1 b)。

每个物理卷映射完整的(即一个SSD的容量是通过逻辑卷管理器(Logical Volume Manager, LVM)创建的(见图1c)。使用lvcreate[40]、[41]将这些多个物理卷合并成一个剥离的逻辑卷。写入到这个逻辑卷的数据由文件系统以分段方式跨所有磁盘进行布局。这个逻辑卷的大小等于所有ssd的总容量。表1给出了我们平台的详细硬件配置。

分析了关系型数据库和NoSQL数据库应用程序(MySQL、MongoDB、RocksDB、Canssandra、ForestBD等)在不同工作负载下的性能。我们注意到关系型数据库应用程序的操作与NoSQL数据库应用程序的操作有很大的不同。关系数据库应用程序执行更高比例的随机输入/输出操作(如图8所示)，从而比NoSQL数据库应用程序[42]、[43]、[44]、[45]占用更多内存。因此，在这里，我们选择使用MySQL46和Cassandra [47] (NoSQL数据库)的不同工作负载来显示和讨论我们的结果，以进行docker性能分析。这两个数据库应用程序不仅是最流行的关系型数据库和NoSQL数据库应用程序，而且也被使用docker的公司广泛采用。分别在MySQL容器中运行TPC-C基准[48]和Cassandras内置基准测试工具cassandra-stress[49]的工作负载。

我们评估了同质和异质container传输的两种不同场景。同构的容器流量是由在相同的工作负载资源下运行相同应用程序的容器造成的(例如，客户机线程、数据集大小、读/写比率等)。异构的集装箱运输是由运行不同工作负载和不同应用程序的容器引起的。

EXPERIMENTAL RESULTS

在本节中，我们将展示在ssd上扩展容器化docker实例的结果。我们尝试增加同时运行的实例数目。我们评估了两种不同类型的配置:1)均质和2)非均质。对于每一种情况，我们使用FIO基准[50]来交叉验证我们从I/O密集型应用中获得的观察结果。在本文的其余部分，我们将把NVMe ssd与磁盘互换使用，以指代持久存储设备。注意，我们提到“写工作负载”时，我们指的是更新操作。我们在运行数据库工作负载时观察和分析有趣的特性。我们注意到8到16个同时放置的容器足以讨论我们所有有趣的观察结果。此外，我们在评估中确实考虑了更多(> 25)docker容器。但是，我们的实验结果表明，当系统中同时运行8个$ 16容器时，资源(例如磁盘或CPU)已经被satu占用，见图2、3、4、5、6、7、8、9、10和11。因此，我们通过使用足够数量的容器来讨论我们的观测结果。

4.1 Homogeneous Docker Containers

我们通过使用MySQL和Cassandra应用程序来探索同构的docker容器。我们首先尝试增加MySQL容器的数量，以观察尽管磁盘带宽的利用率已经饱和，但由于CPU使用率的增加，应用程序的吞吐量也随之增加。第二，我们用Cassandra做实验，100%的写(也就是100%的写)。工作负载，它也随着容器数量的增加而扩展，但是受到CPU利用率饱和的限制。第三，我们使用Cassandra进行100%读工作负载的实验，其中我们注意到吞吐量谷的一个有趣的观察结果。然后，我们研究这种吞吐量谷背后的原因是页面缓存和内存。最后，我们通过构建一个类似的FIO基准工作负载设置来交叉验证吞吐量谷观察。

图2显示了MySQL独立容器化实例的结果。MySQL的工作负载配置如表2所示。图2a显示了MySQL的容器化实例(TPC-C工作负载)随着容器数量的增加可以很好地扩展。我们观察到，尽管每个容器实例的吞吐量都在下降，但MySQL容器的累计吞吐量却随着同时执行容器的数量的增加而增加。累计吞吐量是所有同时运行的容器的吞吐量之和。图2b和2c显示，在四个同时执行的容器中，磁盘带宽利用率达到饱和，但是随着同时执行的容器数量的增加，累积吞吐量随着CPU利用率的增加而不断增加。图3a进一步显示了同构MySQL TPC-C工作负载下所有容器的平均95%延迟作为容器数量的函数。我们观察到模拟执行容器的平均95%延迟随着同时执行容器的数量的增加而增加。因此，我们注意到，在添加更多容器时，在累积吞吐量和I/O延迟之间存在权衡。

类似的实验是使用Cassandra应用程序对100%写(Cassandra_W)和100%读(Cassandra_R)进行的。Cassandra_W和Cassandra_R的工作负载配置如表2所示。图4a显示，容器化的Cassandra实例100%写规模随着容器数量的增加，直到6个同时存在的容器。从图4b可以看出，由于CPU利用率的饱和，吞吐量会饱和，从而进一步增加容器的数量。即使在吞吐量达到6个容器的饱和之后，注意延迟也会随着同时存在的容器数量的增加而增加(参见图4a和图3b)。

因此，从以上两个实验(即， MySQL TPC- C工作负载和Cassandra_W工作负载的Cassandra)，我们注意到，与磁盘作为瓶颈相比，CPU作为瓶颈对整体性能的影响更剧烈。因此，为了实现所有容器的最大吞吐量和最小延迟，同时运行的容器的最佳数量应该是CPU达到饱和的容器数量。

接下来，我们使用Cassandra_R研究100%读工作负载下的性能，工作负载详细信息见表2。图5a显示了容器化实例的锯齿状行为。在容器实例的数量增加到3个之前，可以观察到异常高的性能。这是因为，在将数据从磁盘一次提取到主存之后，读取操作主要是从内存和页面缓存中进行的。四个及以上容器的合并大小不足以容纳页面缓存和内存。因此，将数据换入和换出会导致更高的磁盘访问次数。由于磁盘访问延迟远远高于页面缓存和内存访问延迟，所以当同时存在的容器数量超过4个时，吞吐量就会下降，因为有大量的磁盘I/O操作。然后，吞吐量将受到磁盘带宽的限制。图5b显示只读操作的最大CPU利用率较低(即与只写操作相比(即，65%)。，在图4b中为90%)。图5c进一步显示，最初，对于少量同时发生的容器化实例，大多数读取操作都是从内存中执行的，这使得磁盘带宽利用率很低。但是，当同时在四个容器中观察到吞吐量谷时，大多数操作都是从磁盘执行的。这将导致磁盘带宽利用率的增加和饱和。

为了交叉验证上面观察到的吞吐量谷异常现象，我们使用I/O生成基准，称为FIO (Flexible I/O)[50]。我们开发FIO工作负载来生成复制Cassandra_R工作负载的I/O行为的随机读操作。每个固定的FIO实例的大小设置类似于Cassandra容器运行Cassandra-stress读工作负载的数据集大小。为了观察内存操作的效果，在这个FIO实验中没有绕过页面缓存。

图6显示了FIO基准测试的容器化实例的结果。为了获得与Cassandra_R实验类似的设置，每个FIO容器都要打开大小为50gb的文件。FIO工作负载是大小为4K的随机读取，作业大小为32,IO深度为32。图6还显示了如图5所示的吞吐量谷。图6进一步显示，在6、7和8个并发实例中观察到的读操作的累计吞吐量非常接近磁盘的额定吞吐量。因此，上述观测结果交叉验证了吞吐量谷效应。

总之，对于写密集型应用程序，如果CPU不是瓶颈，那么增加同构容器的数量将增加吞吐量，直到CPU达到饱和。另一方面，对于写密集型应用程序，一旦CPU达到饱和，那么增加容器数量只会增加延迟，而不会提高吞吐量。最后，如果应用程序读得很多，并且容器中执行的应用程序访问的数据库的大小很小，那么它的主要操作可以从页面缓存和内存中执行。对于这种情况，建议在落入吞吐量谷之前限制容器的数量。

4.2 Heterogeneous Docker Containers

我们通过同时运行MySQL和Cassandra应用程序来探索异构的docker容器。我们做了一个有趣的观察，当同时运行时，MySQL的吞吐量下降到其在同类实验中观察到的独立吞吐量的50%以上。但是，在同类实验中观察到的Cassandra的吞吐量只降低了它的单机吞吐量的16%左右。因此，我们说，一个不公平的行为是观察到在这个异质容器混合。在这里，公平性意味着当N个应用程序容器被同时调度来同时运行时，没有一个应用程序容器的吞吐量降低超过它们的单机吞吐量的1/N%。为了研究不公平吞吐量下降的原因，我们对不同类型的异构混合进行了实验，例如:1)Cassandra与FIO随机写负载;2)卡桑德拉与FIO顺序写工作量;和3)卡桑德拉与FIO随机读取工作负载。对于所有的异构实验，我们报告了两个应用程序相同数量的操作容器的结果。（共16个容器，每个程序用8个容器)。
图7显示了同时运行Cassandra和MySQL的容器实例的结果，其工作负载配置为Cassandra_W和TPC-C，如表2所示。图7a和图7b分别显示了Cassandra和MySQL的应用程序吞吐量。例如，图7a的第一个栏表示Cassandra的吞吐量，在总共两个实例中，Cas- sandra和MySQL同时运行。因此，我们显示了多达16个容器的结果，其中包括同时运行的8个Cassandra和8个MySQL容器。我们观察到Cassandra和MySQL之间的不公平吞吐量节流。图4中单机同伦- neous Cassandra实例的最佳吞吐量为60K op率。从图2可以看出，对于8个并发的TPC-C容器，使用同构MySQL实例的最佳吞吐量是18K TpmC。但是，对于同时运行Cassandra和MySQL容器的异构实验，从图7a和图7b可以观察到Cassandra和MySQL的最佳吞吐量分别为50K op rate和9K TpmC。在比较独立的同构部署和异构部署中应用程序的吞吐量时，我们注意到Cassandra的平均吞吐量降低约16%(即，由60K至50K op率)。但是MySQL容器的吞吐量降低了大约50%(即， 18K至9K TpmC)。因此，当在异构设置中同时操作两个应用程序容器时，MySQL容器要比Cassandra容器牺牲更多。从图3c还可以看出，对于这种异构的设置，MySQL的延迟比Cassandra的延迟增加的速度更快。

这是一个有趣的观察，我们相信应用程序的性质起着重要的作用。在异构环境中同时运行不同应用程序的容器时，我们观察到更好的资源利用率，如CPU和磁盘。但是，我们不希望将这样的应用程序容器分组在一起，因为在这样的组合中，一些应用程序的吞吐量和性能被极大地牺牲了。

我们预计，这种不公平的吞吐量分布的原因可能是DRAM内存控制器，它支持顺序写比随机写[51]，[52]，[53]。Cassandra基于日志结构合并(LSM)树，它总是比MySQL[42]、[43]、[44]、[45]执行更多的顺序写操作。图8a和8b显示了Cassandra_W和TPC-C工作负载下，Cassandra和MySQL中总写I/Os中顺序写和随机写的比例。从图8a可以看出，对于任何数量的同时运行的Cassandra容器，顺序写的比例都在80%以上。相反，从图8b可以看出，MySQL容器执行随机写操作的比例要高于顺序写操作。我们还观察到，增加同时操作容器的数目会增加这两个应用程序随机写操作的比例(例如， Cassandra和MySQL)。这可以归因于数据放置期间碎片的增加。

为了验证由于应用程序的性质而导致的不公平吞吐量节流，我们进行了以下三个实验。首先，我们用FIO随机写运行Cassandra_W的并发实例。我们期望看到类似的不公平的吞吐量限制，与各自独立的同类操作相比，FIO随机写入器的容器牺牲的吞吐量高于Cassandra。正如预期的那样，图9显示了不公平的吞吐量节流。独立的均匀FIO随机写容器的最佳吞吐量是250k IOPS，但是我们在图9b中观察到的最大吞吐量是134k IOPS。这验证了最初的假设，即如果一个应用程序的容器中有较高比例的连续写操作与另一个执行随机写操作的应用程序的容器同时操作，那么执行随机写操作的应用程序的吞吐量相对于其独立的同构操作吞吐量会受到严重影响。

其次，我们在图10中展示了使用FIO顺序写保持器同时操作Cassandra容器的结果。在这两个应用程序下，我们看到了几乎相当高的吞吐量，因为这两个应用程序的容器都在执行顺序写操作。图10显示了同时使用FIO顺序写操作Cassandra的结果。独立的同类FIO顺序写实例的最佳吞吐量是6,500个IOPS。从图10中，我们观察到每个应用程序的吞吐量分别只下降了10%到15%。因此，正如预期的那样，我们观察到合理的吞吐量节流。

第三，为了研究模拟操作的写密集型和读密集型应用容器的行为，我们在图11中展示了Cassandra_W容器与FIO随机读容器同时操作的结果。独立的同构FIO随机读实例的最佳吞吐量是450k IOPS。从图11中，我们观察到两个应用程序的吞吐量分别只下降了10%到15%。因此，将写密集型和读密集型应用程序的容器组合起来可以实现更好的资源利用率和公平的吞吐量分配。

因此，我们总结说，不同应用程序的异构组件能够更好地利用CPU和磁盘等整体资源。但是，不建议混合执行顺序写(或读)和随机写(或读)的应用程序容器，因为所观察到的吞吐量分布是不公平的。

5 IMPLICATIONS

在本节中，我们为同类和异构容器化docker平台提供高级设计指南。 这些是有关如何选择要同时运行的应用程序类型的指南。 对于同类情况，我们特别分析了容器的写密集型和读密集型同类分组的行为。 我们提出以下准则来确定同时运行的同类容器的最佳数量：

• 如果应用程序是写密集型的，那么增加同构容器的数量，直到CPU达到satu级别，增加吞吐量。
• 如果应用程序读得很密集，并且所有应用程序容器的工作集大小都很小，以至于它的大部分操作都可以从页面缓存执行，那么建议在进入吞吐量谷之前限制容器的数量。

与VM相比，使用Docker时，由于Docker执行的共享资源管理中存在更高的资源争用可能性，因此，工作负载的异构混合放大了使用Docker时的影响。对于异质的情况，我们的结论是不同应用的容器的有效的异质混合导致更好的资源利用和应用程序吞吐量。对于良好的非均相混合的选择，我们提出了指导原则：

• 不建议混合执行顺序写(或读)和随机写(或读)的应用程序容器，因为所观察到的跨容器的吞吐量分布是不公平的。在这种情况下，应用程序的吞吐量可能会急剧下降。
• 执行具有相似特征的应用程序的联合调度容器(例如，两者都具有大多数连续写操作)导致应用程序容器之间的吞吐量与它们各自独立的同构操作吞吐量相比有一定的限制。
• 将写密集型和读密集型应用程序的容器组合在一起可以实现更好的资源利用率，并实现公平的吞吐量降低。在这种情况下，尽管并发容器的数量增加了一倍，但是与各自应用程序的独立实现相比，每个应用程序的累积吞吐量只下降了10%左右。

6 CONTAINER CONTROLLER

Docker容器是轻量级的，没有来宾操作系统，可以在需要时启动它们。这为我们提供了一个在运行时动态调度和启动Docker容器的好机会。正如上面的指南所示，同时操作更多的容器可以提高系统的利用率。但是，同时运行不同应用程序的所有容器不是一个好主意，因为它不能保证最小的make-span(即，所有这些应用程序的总执行长度)。同时启动所有工作负载容器可能会由于资源争用而增加事务失败，从而导致重新执行那些失败的事务所需的额外时间。正如第4节中所观察到的，不同应用程序的容器之间也可能发生不公平的吞吐量限制。因此，在本节中，我们提出了一个新的容器控制器，以确定在充分利用资源和避免严重的资源争用的目标下，哪些容器应该在同一批中同时操作。在我们的控制器设计中，我们假设用户知道在调度之前需要调度的所有工作负载容器。

6.1 Architecture

为了评估我们的控制器的可行性，我们在Linux内核中将其实现为一个可加载模块。我们的控制器模块插在Docker引擎的顶部，以控制Docker容器处理功能，如Docker_start、Docker_wait、Docker_run、Docker_exec、Docker_pause等。如图12所示，给出了控制器各部件的外围结构示意图。每个应用程序工作负载首先被送入工作负载特征检测器(WCD)， WCD负责根据每个工作负载的特征对其进行标记。为了获得特定工作负载的特征，WCD需要对这个工作负载进行采样，方法是在本地主机上运行一小段时间(例如5分钟)，然后使用一些跟踪收集工具(例如blktrace)在块层收集I/O块跟踪。然后使用解析器工具(如blkparse)解析收集的I/O块跟踪，以分析workloads。然后，WCD将该工作负载放入包含具有相同特征的workload character bins中，如图12所示。工作负载字符箱的总数取决于工作负载的类型。通过利用第5节中导出的分组指导原则，控制器分析了将不同的工作负载分组的代价，然后将workloads分组到每个可用设备的最佳batches/bins中。最后，这些独立的workload batches被安排在应用程序层逐个运行。

我们给出了一个例子来说明控制器是如何确定罚值的。从设计含义来看，我们知道将读密集型工作负载和写密集型工作负载结合起来是有益的。因此，结果的惩罚被设置为null。另一方面，我们的指导原则表明，将工作负载分组为随机写和顺序写的更高比例不是一个好主意。因此，对于这种组合将设置正的惩罚。

控制器的目的是将workloads从workload character bins打包为不同的批处理，以便可以将操作损失和批处理数量都最小化。 在这里，每个批次应包含一组将同时运行的容器化工作负载。 此外，如果有多个逻辑卷的存储驱动器可用，则控制器应为这些逻辑卷考虑多组批处理，请参见图1。

6.2 Problem Formulation

现在，我们给出了这个优化问题的数学公式。假设每个应用程序有n个应用程序和m个容器。比如, 共有 n m 个containers.每个容器只能属于一个workload character bins.。不失一般性，我们假设n和m都是正整数。同时从不同的workload character bins.中运行workloadAi和Aj可能会根据它们的特性带来一些损失。我们使用Sij来表示Ai和Aj之间的冲突，如果它们在同一个运行批中同时运行。

在此基础上，我们建立了一个由不同的相对罚权组成的罚矩阵。(Sij)来区分同时运行两个容器时性能干扰的严重程度。更详细地说，我们根据第5节中推导的实验含义配置了惩罚矩阵的相对权重，并使用不同的Sij值(例如，0,1,2)来表示同时运行容器i和容器j时的相对惩罚。例如，运行一个读密集型工作负载和另一个写密集型工作负载的惩罚权重可以设置为0，因为不会发生性能干扰，这意味着更好地利用资源是一个很好的决策。相比之下,点球运行顺序写工作负载写卡桑德拉的工作负载(如100%)和一个随机写工作负载(比如MySQL编写工作量100%)可以相对较高(例如,2)的重量值,因为我们可以观察到的性能下降的随机写操作工作量显著显著。因此，我们可以构建一个矩阵(参见图13中的示例)来列出所有给定容器可能的冲突代价。惩罚矩阵的大小为n m x n m.

每个给定的容器只运行一次，因此每个容器只属于一个正在运行的批处理。一个简单的情况是在每个运行批中运行一个容器，这样我们就有最大的运行批数，它等于容器的总数(即n m)。显然，在这种情况下，系统资源可能没有得到充分利用，这些应用程序的执行时间也无法减少。另一种简单的方法是在同一批中运行所有容器。在这种情况下，所有应用程序都将争用可用资源，这可能会导致争用和节流。因此，控制应用程序容器的并发性非常重要。我们的控制器主要有两个目标，即:，批次的数量和冲突惩罚(例如，不公平的吞吐量节流)都应该最小化。Eq。(1)给出了总处罚(Tp)和Eq冲突。(2)显示批次的总数(NzÞ,Sij违约成本项目之间Ai和Aj当分组在同一批次,实物支付债券是一个二进制变量,如果物品Ai是装在批k = 1,否则为0,和zk是一个二进制变量等于1如果使用批处理k,否则为0

我们把这个问题转化成一个目标函数，从而最小化总误差和总误差。我们的控制器的目标是使干扰补偿成本(Tp)和最大完工时间(Nz)最小化，即，所有I/O工作负载的总体执行时间。我们在Eqs中定义了这两个性能指标。(1)及(2)，并以尽量减少(即在一个目标函数中。但是，我们知道，Tp和Nz的单位和取值范围是不同的。我们进一步使用MIN-MAX归一化方法对[0,1]范围内的Tp和Nz值进行了缩放，并通过对两个归一化项求和来考虑两个指标的相同权重，如式(3)所示。我们注意到在目标函数中也可以采用不同的权值。由于我们的目标是最小化Tp和Nz，所以我们构建的目标函数是通过添加这两个规范化项来实现函数的最大化。用于描述优化问题的数学公式的变量见表3。

求解目标函数的约束条件在Eqs中列出。(4)、(5)、(6).约束C1表示工作负载Ai是否在批量k中运行。最后，根据平台规范，用户可能希望限制并发容器的最大数量，然后通过约束C3强制执行。因此，控制器的目标是确定最优矩阵P，从而获得优化函数f的最大值，P给出调度信息，即工作负载Ai可以在批量k中运行，如果1 / 4 1或者相反。例如，如图14所示，项目P31为1，表示应用程序容器A3在第一次批处理中运行。

6.3 Techniques for Solving Optimization Problem of Controller

解决这一凸优化问题的最简单方法是通过生成所有可能的p来对目标函数进行蛮力评估。这种方法无疑为我们提供了可能的最佳工作负载批次，从而确保了最小的代价和最小的批次数量。但是，由于问题的高度复杂性，这种蛮力方法很难解决实际中经常出现的大规模实例。此外，它是高时间消耗。因此，我们用两种线性规划算法求解优化函数，并在Matlab中实现约束矩阵优化。我们使用了由Matlab提供的内点(IP)和标准二次规划(SQP)算法。其他所有由Matlab提供的优化算法(R2017a -学术版)都不适用于解决我们的优化问题。利用以上每一种算法，我们进一步调整了两个可能的局部搜索和全局搜索选项，分别得到local1和全局极大值。在我们的解决方案中，我们将支持的最大并发应用程序容器数(’)视为 n * m。

6.4 Results

接下来，我们给出了控制器的结果，它使用优化目标函数来调度工作负载控制器。在这里，我们比较了性能结果以及使用不同优化算法的开销。我们的平台在三个ssd上有一个单独的逻辑卷，以提供3tb的存储空间。详细的平台配置请参考第3.2节。如表4所示，我们使用5个不同的应用程序作为不同I/O行为的代表，然后为每个应用程序配置5个具有不同参数设置(例如，更新数量、线程数量)的工作负载。两个数据库应用程序(即， MySQL和Cassandra)也可以在表2中找到。对于每个工作负载，我们有固定的记录大小(例如，1 KB)。但是要改变记录的数量。因此，对于每个工作负载(甚至来自同一个应用程序)，我们可以有不同的记录大小，从50 GB到100 GB不等。

因此，我们有5个容器来运行每个应用程序，在这个实验中总共有25个容器来评估我们的控制器。我们的控制器的目标是确定这25个容器的最佳运行批次。实际上，我们确实考虑过在我们的实验中使用更多的容器。但是，我们在第4节中的实验结果表明，当系统中同时运行8个$ 16容器时，资源(例如磁盘或CPU)已经饱和，参见图2、图4和图5。在所有资源都被充分利用之前，控制器可以获得性能改进。饱和后，容器数量的进一步增加并不能带来更好的性能。考虑到这一点，我们考虑在这个实验中使用最多25个不同的容器(或I/O密集型数据库工作负载)。限制我们使用25个容器进行实验的另一个原因是，相关工作负载数据库的数据加载和预热开销很高。具体来说，容器中每个工作负载的平均数据库大小约为50 $ 100 GB。我们花了大约一周的时间来设置总共25个容器的数据库。

图15为目标函数(即在不同的优化技术下，最大、最小和离均值一个标准差。由于我们的目标函数的目标是使值最大化，所以值越高越好。图15中y轴上的目标函数值是在考虑Eqs中给出的约束条件下，对式(3)中提到的优化函数进行评估的结果。(4)、(5)、(6)。图15的x轴表示6.3节讨论的不同优化方法的结果。我们可以看到，蛮力3 (BF)方法得到了最佳极大值和最小极大值，因为它尝试了所有可能的P矩阵。其中每个P矩阵表示可能的工作负载批次组合。内点和标准二次规划方法都使用了近似的导数求解器。因此，即使对于相同的输入参数，每次运行的结果也略有不同。因此，对于剩下的4个方法，我们得到它们的结果，每个结果独立运行超过50次，每个运行中迭代超过50次。

我们进一步注意到，虽然蛮力方法为我们的目标函数提供了最佳的最大值，但是BF的操作非常耗时，因为蛮力算法计算所有可能的组合。这个蛮力方法的复杂性是OððnmÞ!Þ这只是好当n和m的值很小。

我们观察到这两种全局搜索方法，即， IP-G和SQP-G，也实现了我们目标函数的一个很好的最大值。这些算法的最大值与蛮力求值的最大值非常接近，见图15。更重要的是，这些全局评估技术比蛮力方法消耗更少的时间。每个优化方法都要花费一些时间来解决称为该方法开销的问题。当蛮力方法评估所有可能的测试用例时，它具有最大的可能开销。图16显示了四种优化算法与蛮力算法比较后的非malized开销。我们可以看到，两种全局搜索算法使用的时间不到蛮力方法的4%。两种局部搜索算法消耗的开销更少。但是，它们不能提供全局搜索方法和极大值，参见图15和16中的IP-L和sql - l。注意，图16所示的控制器开销包括图12所示控制器的所有组件的开销，如WCD标记时间、优化目标功能所花费的时间和管理延迟。

为了进一步研究其对实际性能的影响，我们对五种不同应用的25个容器进行了实际实验，结果如表4所示。图17显示了使用来自controller w.r.t.基线的结果来加速所有容器的执行时间，其中所有应用程序容器都是在没有任何控制器的情况下立即启动的。在我们的评估中，基线情况下的执行时间约为600小时。在图17中，我们还给出了每个控制器在相应条上的实际执行时间(小时)。通过适当的容器调度，所有工作负载的总体执行速度可以比一次启动所有应用程序容器而不做任何调度工作的情况更快。结果表明，优化后的高炉质量最佳，提高了生产效率。全局搜索方法(即， IP-G和SQP-G)的加速效果与BF非常相似。使用IP-L和sql - l的本地搜索只提供10%的工作负载执行速度提升。

最后，我们通过考虑执行速度和时间开销来评估总体效率，因为控制器所需的操作可能也会消耗一些额外的时间。图18显示了总体运行时(即，应用程序执行时间加上控制器求解目标函数的时间)。基线仍然是没有控制的情况。同样，每个条上的值表示每个算法的实际总运行时间(以小时为单位)。显然，BF方法由于开销大而失去了其优越性。相比之下，这两种全局搜索方法成为了最好的，总体上提高了35%到40%的速度。

7 CONCLUSION

在本文中，我们研究了在多个ssd的剥离逻辑卷上，docker数据卷支持的同时运行的docker容器数量的增加对性能的影响。我们分析了应用程序在同构和异构环境中的吞吐量。我们挖掘了有趣的观察背后的原因，并通过使用FIO基准测试工作负载进一步验证它们。据我们所知，这是第一项研究工作，以探索重要的现象，如容器化的docker环境的吞吐量。此外，我们的工作表明，同时运行执行顺序写(或读)和随机写(或读)的应用程序容器是不可取的。在本文中，我们提出了一些与性能工程相关的设计准则，然后开发了一个工作负载控制器来有效地调度所有应用程序容器的启动时间。我们展示了我们的控制器可以决定可以同时运行的docker容器的批次，这样可以减少总体执行时间并避免工作负载干扰(如不公平的吞吐量限制)。在未来，我们计划嵌入带有开源docker引擎安装的docker控制器，这样用户只需选择一个自动调度选项就可以轻松地使用它。

REFERENCES

1] Wikipedia, “Docker (software)—wikipedia - the free encyclopedia,” 2016. [Online]. Available: https://en.wikipedia.org/w/index.php? title=Docker_(software)&oldid=728586136. Accessed on: Jul. 12, 2016.
[2] C. Anderson, “Docker software engineering,” IEEE Softw., vol. 32, no. 3, p. 102–c3, 2015.
[3] P. Di Tommaso, E. Palumbo, M. Chatzou, P. Prieto, M. L. Heuer, and C. Notredame, “The impact of docker containers on the per- formance of genomic pipelines,” PeerJ, vol. 3, 2015, Art. no. e1273.
[4] J. Fink, “Docker: A software as a service, operating system-level virtualization framework,” Code4Lib J., vol. 25, p. 29, 2014.
[5] W. Felter, A. Ferreira, R. Rajamony, and J. Rubio, “An updated performance comparison of virtual machines and Linux contain- ers,” in Proc. IEEE Int. Symp. Perform. Anal. Syst. Softw., 2015, pp. 171–172.
[6] R. Dua, A. R. Raja, and D. Kakadia, “Virtualization versus con- tainerization to support PaaS,” in Proc. IEEE Int. Conf. Cloud Eng., 2014, pp. 610–614.
[7] A. Olbert, et al., “Managing multiple virtual machines,” U.S. Patent 10 413 440, 2003.
[8] M. Ronstrom and L. Thalmann, “MySQL cluster architecture over- view,” MySQL Technical White Paper, 2004.
[9] K.-T. Seo, H.-S. Hwang, I.-Y. Moon, O.-Y. Kwon, and B.-J. Kim, “Performance comparison analysis of Linux container and virtual machine for building cloud,” Adv. Sci. Technol. Lett., vol. 66, pp. 105–111, 2014.
[10] R. Rosen, “Resource management: Linux kernel namespaces and cgroups,” Haifux, vol. 186, May 2013.
[11] Q. Xu, M. Awasthi, K. Malladi, J. Bhimani, J. Yang, and M. Annavaram, “Performance analysis of containerized applica- tions on local and remote storage,” in Proc. Int. Conf. Massive Storage Syst. Technol., 2017.
[12] Q. Xu, M. Awasthi, K. Malladi, J. Bhimani, J. Yang, and M. Annavaram, “Docker characterization on high performance SSDs,” in Proc. IEEE Int. Symp. Perform. Anal. Syst. Softw., 2017, pp. 133–134.
[13] J. Bhimani, Z. Yang, M. Leeser, and N. Mi, “Accelerating big data applications using lightweight virtualization framework on enter- prise cloud,” in Proc. 21st IEEE High Perform. Extreme Comput. Conf., 2017, pp. 1–7.
[14] M. Canim, G. A. Mihaila, B. Bhattacharjee, K. A. Ross, and C. A. Lang, “SSD bufferpool extensions for database systems,” in Proc. VLDB Endowment, vol. 3, no. 1/2, pp. 1435–1446, 2010.
[15] L.-P. Chang, “Hybrid solid-state disks: Combining heterogeneous NAND flash in large SSDs,” in Proc. Asia South Pacific Des. Autom. Conf., 2008, pp. 428–433.
[16] G. Soundararajan, V. Prabhakaran, M. Balakrishnan, and T. Wobber, “Extending SSD lifetimes with disk-based write caches,” in Proc. USENIX Conf. File Storage Technol., 2010, pp. 101–114.
[17] H. Jo, Y. Kwon, H. Kim, E. Seo, J. Lee, and S. Maeng, “SSD-HDD- hybrid virtual disk in consolidated environments,” in Proc. Eur. Conf. Parallel Process., 2009, pp. 375–384.
[18] T. Luo, R. Lee, M. Mesnier, F. Chen, and X. Zhang, “hStorage-DB: Heterogeneity-aware data management to exploit the full capabil- ity of hybrid storage systems,” Proc. VLDB Endowment, vol. 5, no. 10, pp. 1076–1087, 2012.
[19] R. Chin and G. Wu, “Non-volatile memory data storage system with reliability management,” U.S. Patent 12 471 430, May 25, 2009.
[20] A. Leventhal, “Flash storage memory,” Commun. ACM, vol. 51, no. 7, pp. 47–51, 2008.
[21] Y. Wang, K. Goda, M. Nakano, and M. Kitsuregawa, “Early expe- rience and evaluation of file systems on SSD with database applications,” in Proc. IEEE 5th Int. Conf. Netw. Archit. Storage, 2010, pp. 467–476.
[22] D. Narayanan, E. Thereska, A. Donnelly, S. Elnikety, and A. Rowstron, “Migrating server storage to SSDs: Analysis of tradeoffs,” in Proc. 4th ACM Eur. Conf. Comput. Syst., 2009, pp. 145–158.
[23] D. Schall, V. Hudlet, and T. H€arder, “Enhancing energy efficiency of database applications using SSDs,” in Proc. 3rd C* Conf. Comput. Sci. Softw. Eng., 2010, pp. 1–9.
[24] S. Park and K. Shen, “A performance evaluation of scientific I/O workloads on flash-based SSDs,” in Proc. IEEE Int. Conf. Cluster Comput. Workshops, 2009, pp. 1–5.
[25] S. Boboila and P. Desnoyers, “Performance models of flash-based solid-state drives for real workloads,” in Proc. IEEE 27th Symp. Mass Storage Syst. Technol., 2011, pp. 1–6.
[26] H. Fujii, K. Miyaji, K. Johguchi, K. Higuchi, C. Sun, and K. Takeuchi, “x11 performance increase, x6. 9 endurance enhancement, 93% energy reduction of 3D TSV-integrated hybrid ReRAM/MLC NAND SSDs by data fragmentation suppression,” in Proc. Symp. VLSI Circuits, 2012, pp. 134–135.
[27] T. Y. Kim, D. H. Kang, D. Lee, and Y. I. Eom, “Improving perfor- mance by bridging the semantic gap between multi-queue SSD and I/O virtualization framework,” in Proc. 31st Symp. Mass Stor- age Syst. Technol., 2015, pp. 1–11.
[28] V. K. Vavilapalli, et al., “Apache hadoop YARN: Yet another resource negotiator,” in Proc. 4th Annu. Symp. Cloud Comput., 2013, Art. no. 5.
[29] A. Takefusa, H. Nakada, T. Ikegami, and Y. Tanaka, “A highly available distributed self-scheduler for exascale computing,” in Proc. 9th Int. Conf. Ubiquitous Inf. Manage. Commun., 2015, Art. no. 56.
[30] Docker Swarm. Accessed on: Jan. 20, 2018.
[31] B. Hindman, et al., “Mesos: A platform for fine-grained resource
sharing in the data center,” in Proc. 8th USENIX Conf. Netw. Syst.
Des. Implementation, 2011, pp. 295–308.
[32] K. Li, H. Liu, Y. Wu, and X. Xu, “A two-dimensional bin-packing
problem with conflict penalties,” Int. J. Prod. Res., vol. 52, no. 24,
pp. 7223–7238, 2014.
[33] N. Karmarkar and R. M. Karp, “An efficient approximation
scheme for the one-dimensional bin-packing problem,” in Proc.
23rd Annu. Symp. Found. Comput. Sci., 1982, pp. 312–320.
[34] A. Scholl, R. Klein, and C. Ju€rgens, “BISON: A fast hybrid proce- dure for exactly solving the one-dimensional bin packing prob-
lem,” Comput. Operations Res., vol. 24, no. 7, pp. 627–645, 1997.
[35] R. Sridhar, M. Chandrasekaran, C. Sriramya, and T. Page, “Optimization of heterogeneous bin packing using adaptive genetic algorithm,” in Proc. IOP Conf. Series: Mater. Sci. Eng., 2017,
Art. no. 012026.
[36] B. Schulze, L. Paquete, K. Klamroth, and J. R. Figueira, “Bi-dimensional knapsack problems with one soft constraint,”Comput. Operations Res., vol. 78, pp. 15–26, 2017.
[37] T. K. Ghosh, S. Das, S. Barman, and R. Goswami, “A comparison between genetic algorithm and cuckoo search algorithm to mini- mize the makespan for grid job scheduling,” in Proc. Int. Conf. Comput. Intell., 2017, pp. 141–147.
[38] M. Paul, R. Sridharan, and T. R. Ramanan, “A multi-objective decision-making framework using preference selection index for assembly job shop scheduling problem,” Int. J. Manage. Concepts Philosophy, vol. 9, no. 4, pp. 362–387, 2016.
[39] H. Afsar, P. Lacomme, L. Ren, C. Prodhon, and D. Vigo, “Resolution of a Job-Shop problem with transportation con- straints: A master/slave approach,” IFAC-PapersOnLine, vol. 49, no. 12, pp. 898–903, 2016.
[40] M. Hasenstein, “The logical volume manager (LVM),” White paper, 2001.
[41] G. Banga, I. Pratt, S. Crosby, V. Kapoor, K. Bondalapati, and V. Dmitriev, “Approaches for efficient physical to virtual disk conversion,” U.S. Patent 13 302 123, 2013.
[42] How to fix MySQL high memory usage?. Accessed on: Sep. 04, 2017.
[43] J. Schad, J. Dittrich, and J.-A. Quian e-Ruiz, “Runtime measure- ments in the cloud: Observing, analyzing, and reducing variance,” Proc. VLDB Endowment, vol. 3, no. 1/2, pp. 460–471, 2010.
[44] How MySQL Uses Memory. Accessed on: Sep. 04, 2017.
[45] D. McCreary and A. Kelly, Making Sense of NoSQL. Shelter Island, NY, USA: Manning, 2014, pp. 19–20.
[46] A. MySQL, “MySQL database server,” Internet WWW page, 2004. [Online]. Available: http://www. mysql. com
[47] A. Lakshman and P. Malik, “Cassandra: A decentralized struc- tured storage system,” ACM SIGOPS Operating Syst. Rev., vol. 44, no. 2, pp. 35–40, 2010.
[48] Francois, W. Raab, A. Kohler, and Shah, MySQL TPC-C Benchmark. [Online]. Available: http://www.tpc.org/tpcc/detail.asp. Accessed on: Sep. 6, 2016.
[49] Cassandra-Stress Benchmark. [Online]. Available: https://docs. datastax.com/en/cassandra/2.1/cassandra/tools/toolsCStress_t. html. Accessed on: Sep. 6, 2016.
[50] FIO - Flexible I/O Benchmark. [Online]. Available: http://linux.die. net/man/1/fio. Accessed on: Sep. 7, 2016.
[51] L. R. Mote Jr, “Memory controller which executes read and write commands out of order,” U.S. Patent 5 638 534, Jun. 10, 1997.
[52] S. Rixner, W. J. Dally, U. J. Kapasi, P. Mattson, and J. D. Owens,“Memory access scheduling,” ACM SIGARCH Comput. Archit.News, vol. 28, no. 2, pp. 128–138, 2000.
[53] R. J. Bowater, S. P. Larky, J. C. S. Clair, and P. G. Sidoli, “Flexible dynamic memory controller,” U.S. Patent 5 301 278, Apr. 5, 1994.