云存储性能行为研究及优化方案

+Ⓧ从客户的角度理解云存储的I/O性能行为北京邮电大学中国北京云存储在过去几年中越来越受欢迎。在云存储中，数据存储在服务提供商的数据中心，用户通过网络访问数据。对于这样一个新的存储模型，我们之前关于传统存储的智慧可能不再有效，也不适用于新兴的云存储。在本文中，我们提出了一个全面的研究，以深入了解云存储的独特特征，并从客户端的角度优化云存储的用户体验。与以前的测量工作主要旨在表征云存储提供商或特定的客户端应用程序不同，我们专注于分析各种客户端因素对用户体验性能的影响通过大量的实验和定量分析，我们得到了一些重要的发现。例如，我们发现（1）并行度和请求大小的适当组合可以实现优化的带宽，(2)客户端的能力和地理位置在确定端到端用户可感知性能方面起重要作用，以及（3）混合云存储请求之间的干扰可能导致性能下降。基于我们的研究结果，我们展示了一种基于采样和推理的方法，以确定不同优化目标的适当组合我们进一步提出了一组典型的基于云的应用程序的客户端分块和并行化的案例研究我们的研究表明，应特别注意充分利用客户的能力和云存储服务的巨大潜力类别和主题描述符：D.4.2 [操作系统]：存储管理-二级存储;D.4.8 [操作系统]：性能-测量通用术语：设计、实验、测量、性能其他关键词和短语：云存储，存储系统，性能分析，测量，性能优化ACM参考格式：Binbing Hou，Feng Chen，Zhonghong Ou，Ren Wang，and Michael Mesnier. 2017.从客户的角度了解云存储的I/O性能行为。ACM Trans. Storage 13，2，Article 16（May 2017），36 pages.DOI：http://dx.doi.org/10.1145/3078838本文的早期版本发表在16日的第32届国际会议论文集大规模存储系统和技术（MSST这项工作得到了路易斯安那州董事会的LEQSF（2014-17）-RD-A- 01和LEQSF-EPS（2015）-PFUND-391资助，国家科学基金会的CCF-1453705和CCF-1629291资助，以及英特尔公司的慷慨支持。作者地址：B。Hou和F. Chen（通讯作者），计算机科学与工程系，路易斯安那州立大学，102 G电气工程大楼，巴吞鲁日，LA，USA 70803;电子邮件：{bhou，fchen}@csc.lsu.edu; Z.欧（通讯作者），北京邮电大学计算机科学与工程系，北京市海淀区西土城路10号，邮编100876;邮箱：zhonghong. bupt.edu.cn; R.Wang和M.Mesnier，英特尔实验室，英特尔公司，2111 NE 25 th Ave，Hillsboro，OR，USA 97124;电子邮件：{ren.wang，michael.mesnier}@ intel.com。允许制作部分或全部本作品的数字或硬拷贝供个人或课堂使用，不收取任何费用，前提是复制品不以营利或商业利益为目的制作或分发，并且复制品在第一页或显示器的初始屏幕上显示此通知以及完整的引用。版权的组成部分，这项工作所拥有的其他人比ACM必须尊重。允许用信用进行提取复制，再版，张贴在服务器上，再分发到列表，或在其他作品中使用本作品的任何组成部分，需要事先特定的许可和/或费用。可向出版部索取，ACM，Inc. 2 Penn Plaza，Suite 701，New York，NY 10121-0701USA，传真：1（212）869-0481，或permissions@acm.org。c 2017 ACM 1553-3077/2017/05-ART16 $15.00DOI：http://dx.doi.org/10.1145/3078838ACM Transactions on Storage，Vol.号132、第十六条，公布日期：2017年5月十六B. Hou等人1. 介绍云存储是一个快速增长的市场。根据信息处理服务（IHS）的一份报告，2012年个人云存储订阅量增加到5亿，到2017年将达到13亿[IHS 2012]。 全球市场预计将从2015年的188.7亿美元增长到2020年的654.1亿美元[MarketsandMarkets 2015]。到目前为止，云存储不仅用于归档个人数据，而且在各种核心商业服务中发挥着不可或缺的作用，从按需提供视频到存储非结构化科学数据。对于最终用户来说，云存储特别有趣，因为它提供了一种令人信服的新存储模式。在这个模型中，数据存储在服务提供商的数据中心，用户通过互联网通过基于HTTP的REST协议访问数据。通过在物理上和逻辑上将数据存储与数据使用者分离，这种体系结构实现了巨大的灵活性和弹性，以及非常理想的跨平台能力。另一方面，这样的模型与传统的直接附接存储截然不同：“存储介质”被大规模存储集群替代，其可以由数千个大规模并行化机器组成;“I/O总线”通常是全球互联网，其允许连接两个地理上遥远的端部;严格定义的“I/O协议”被基于HTTP的PC或智能手机）。所有这些属性一起形成了一个相当松散的耦合系统，它与传统的对应系统有着根本的不同。这种变化的一个直接影响是，我们以前关于存储的许多智慧，我们系统优化的基础，可能不再适用于新兴的基于云的存储。这是因为几个原因。首先，存储数据的大规模并行化存储集群可能允许快速有效地处理大量独立的并行I/O相比之下，我们的传统存储强调如何组织顺序I/O模式，以解决旋转介质的限制[Ding et al. 2007; Jiang et al. 2005]。第二，与稳定和快速的I/O总线（如小型计算机系统接口（SCSI））相比，客户端和云之间的冗长Internet连接缓慢，不稳定，有时甚至不可靠。云I/O可能会传输过长的距离（例如，从海岸到海岸数千英里）到服务提供商的数据中心，这可能涉及数十个网络组件，并最终导致数百毫秒甚至更长的I/O延迟。最后，消费数据和驱动I/O活动的客户端在各个方面都高度多样化，从CPU到内存到存储再到通信。某些规格（例如，CPU）直接与客户端处理并行网络I/O的能力相关。不幸的是，我们目前对存储行为的理解大多局限于传统的存储，这是定义良好，并在有限的范围内进行了大量的最近的一些研究对云存储服务[Li et al. 2010; Cooper et al. 2010;Bocchi et al. 2014]和云存储客户端[Cooper et al. 2010; Meng et al. 2010; Drago et al.2013，2014，2012; Gracia-Tinedo et al. 2013; Ou et al. 2015]的性能进行了基准测试。这些研究主要集中在服务器端的基准测试云存储或测试特定的云存储客户端应用程序。在这项工作中，我们认为云存储服务作为一个用户可感知的云存储性能是云和客户端之间交互的结果。云存储中的一个独特挑战是访问同一云的高度多样化的工作云存储客户端可能具有非常不同的能力（例如，智能手机，平板电脑，ACM Transactions on Storage，Vol.号132、第十六条，公布日期：2017年5月从客户的角度理解云存储的I/O性能行为十六台式机、服务器）;即使是同一个客户端，性能也可能不同，例如地理位置的变化导致网络速度这强烈地促使我们深入了解云存储（一种云存储解决方案）的独特I/O行为，特别是从数据消费者的角度在这篇文章中，我们试图回答下面列出的一系列重要问题。成功地回答这些问题不仅可以帮助我们理解几个传统的关键因素的影响（例如，并行化和请求大小）以及若干新问题（例如，客户端能力和地理距离），这是基于云的存储模型所独有的。- 存储容量和请求大小是影响存储性能的两个关键因素。它们对云存储的性能有哪些影响我们能否在并行度和请求大小之间做出CPU、内存和存储是定义客户端功能的三个主要组件。在云存储场景中，影响云存储性能的最关键因素是什么？在不同的工作负载下，它们对性能有什么影响？- 客户端和云之间的地理距离决定了往返时间（RTT），这被认为是影响云存储速度的关键因素这种地理距离对云I/O带宽和延迟有什么影响我们是否应该总是尝试寻找云存储提供商的附近数据中心- 在传统存储中，已经观察到并行读取和写入相互影响[Chen等人，2009]。客户端生成的云存储读取（GET）和写入（PUT）如何相互干扰？哪一个受影响最大？- 云存储提供基于对象的存储服务。请求大小可能不总是相等的。如果大的请求和小的请求混合在一起，效果如何，哪一个对干扰更敏感？- 根据我们对云存储性能的实验研究，相关的系统影响是什么我们如何使用它们来优化客户端应用程序，有效地利用云存储的优势？为了回答这些关键问题，我们从客户的角度对云存储进行了全面的实验从本质上讲，我们的研究将云存储视为一种存储服务，而不是网络服务。因此，我们更感兴趣的是表征客户端感知的端到端性能，而不是中间通信。我们相信这种方法也反映了彻底理解云存储的需求，以实现作为存储解决方案的全系统集成[Chen et al. 2014年]。对于我们的实验，我们开发并运行了一个自制的测试工具在亚马逊简单存储服务（S3）。通过使用存储研究中使用的两个关键指标--延迟和带宽，我们使用五种不同的客户端设置（每个客户端都是一个Amazon EC2实例）执行了一系列实验，同样值得注意的是，我们的主要目的不是对特定云存储服务的速度进行基准测试。我们希望调查与云及其客户端相关的主要因素的端到端影响，并深入了解如何在客户端进行适当的优化。具体来说，我们通过控制比较来调查每个因素。也就是说，我们每次更改基线客户端的一个配置，并观察其对性能的影响ACM Transactions on Storage，Vol.号132、第十六条，公布日期：2017年5月16：4 B. Hou等人我们的贡献可概括如下：- 与主要旨在表征云存储服务或特定客户端应用程序的先前测量工作不同，我们专注于分析客户端相关因素的影响客户端的能力和位置）对用户体验的性能以及客户端和云之间的直接交互的影响。为此，我们构建了一个自制的工具来访问Amazon S3，这是最流行的云存储提供商之一，作为客户端运行在Amazon EC2实例上。通过大量的实验和定量分析，我们得到了一些重要而有趣的发现：（1）并行化I/O和组织大请求是提高客户端感知性能的关键。并行度和请求大小这两个参数的适当组合可以得到最佳带宽（2）客户端能力，包括CPU、内存和存储，在决定端到端性能方面起着重要作用。(3)较长的地理距离会影响客户端感知的性能，但并不总是导致较低的带宽。适当地并行化云I/O可以有效地隐藏长地理距离的影响。(4)混合云存储请求之间的干扰可能会导致性能显著下降，应引起足够的重视。- 基于我们的研究结果，我们提出了一种基于抽样和推理的方法来确定两个关键因素的适当组合：并行度和请求大小。我们还展示了可以采取的实现不同优化目标的可能策略：减少延迟和增加带宽。评价结果表明了该方法的有效性。- 我们进一步提出了一组关于典型基于云的应用程序的客户端分块和并行化的案例研究，包括通知预取，同步和文件系统。在这些案例研究中，我们展示了如何通过适当的客户端优化有效地利用云存储的巨大性能潜力文章的其余部分组织如下。第二节介绍背景。第3节描述了我们实验研究的方法。第4节介绍了观察结果并分析了结果。第5节描述了基于采样和推理的方法。第6节介绍了案例研究。第7节讨论了我们的研究结果的系统影响。相关的工作在第8节中介绍，最后一节总结了这篇文章。2. 阿格罗和2.1. 云存储模型在云存储中，用户数据的基本实体是对象。对象在概念上类似于文件系统中的文件对象以键/值对的形式与某些元数据相关联通常，对象可以由URL指定，该URL包括服务地址、桶和对象名称（例如，https://1.1.1.1:8080/v1/AUTH_test/c1/foo). 最大对象大小通常为5GB，这是HTTP协议的限制[Amazon 2010]。对象被进一步组织成逻辑组，称为存储桶或容器。存储桶/容器类似于文件系统中的目录，但不能嵌套。几乎所有的云存储服务提供商都为用户提供了基于HTTP的表述性状态传输（REST）接口，用于访问云存储对象。有些还提供用于编程的特定于语言的API。两个典型的操作是PUT（上传）和GET（下载），它们类似于传统存储中的写入和读取。还提供了其他操作，例如删除、HEAD和POST，ACM Transactions on Storage，Vol.号132、第十六条，公布日期：2017年5月从客户的角度理解云存储的I/O性能行为十六对象并检索和更改元数据。对于每个操作，URL指定云存储中的目标对象也可以附加其他HTTP头2.2. 云存储服务云存储旨在提供方便的存储服务，具有高弹性，可靠性，可用性和安全性保证。AmazonS3 [Amazon2015c]是最典型和最流行的云存储服务之一其他云存储服务，如OpenStackSwift [OpenStack2011]，共享类似的结构。通常，云存储服务运行在由许多服务器组成的大规模存储集群上，这些服务器用于不同的目的，从处理HTTP请求到记账到存储到桶列表等。这些服务器还可以根据物理位置、机器/机柜、网络连接等在逻辑上组织成分区或区域。为了可靠性，区域/分区彼此隔离，数据副本应单独驻留。简而言之，云存储服务构建在大规模并行化的结构上，并针对吞吐量进行了高度优化。2.3. 云存储应用应用程序可以以不同的方式访问云存储。一些应用程序使用供应商提供的API直接在其软件中编程对云的数据访问这样的API由服务提供商提供，并且通常是语言特定的（例如，Java或Python）。由于云存储对象可以通过指定的URL定位还可以使用curl等工具手动生成HTTP请求，链接.更流行的云存储应用类别是个人文件共享和备份（例如，Dropbox）。这些应用程序通常提供类似文件系统的界面，以允许最终用户访问云存储。从数据交换的角度来看，这些客户端通常使用同步或缓存来增强用户体验。使用同步方法，客户端维护存储在云存储库中的数据的完整副本。同步器守护程序监视更改并定期在客户端和云之间使用缓存方法，客户端仅在本地维护最频繁使用的数据，并且任何缓存未命中都会导致从云中按需获取数据在实践中，几乎所有的个人云存储应用程序都采用同步模式，例如Dropbox [2015]，Google Drive [Google 2015]和OneDrive [Microsoft 2015]。将云作为I/O堆栈的一部分的应用程序和存储系统采用缓存模式，例如RFS [Dong et al. 2011; S3 FS 2015; S3 Backer2015]，BlueSky [Vrable et al. 2012]和SCFS [Bessani et al. 2014]。一般来说，所有上述应用程序本质上都将类似POSIX的文件操作转换为HTTP请求（例如，读取函数调用被转换为GETHTTP请求）。为了准确和直接地观察客户端和云之间的数据交换，我们的研究谨慎地避免使用任何特定的应用技术，镍（例如，缓存和预取），但直接使用HTTP协议，这是云存储中的底层通信协议。这很好地服务于我们的实验目的，为优化云存储客户端提供设计指导，例如做出适当的缓存和预取决策。3. 衡量方法如前所述，我们实验研究的主要目的是从客户端的角度来描述云存储的性能行为在我们的实验中，我们将云视为一个为了避免客户端优化的干扰，我们通过基于HTTP的REST协议仔细生成原始云I/O流量，以直接访问云存储并观察客户端的性能。ACM Transactions on Storage，Vol.号132、第十六条，公布日期：2017年5月十六B. Hou等人表I.基于Amazon EC2的客户端客户端例如位置区vCPU存储器存储基线m1.large俄勒冈美国西部-2a27.5GB磁性（410GB）CPU +c3.xlarge俄勒冈美国西部-2a47.5GB磁性（410GB）MEM-负m1.large俄勒冈美国西部-2a23.5GB磁性（410GB）STOR-SSDm1.large俄勒冈美国西部-2a27.5GB固态硬盘（410GB）GEO-Sydneym1.large悉尼东南-2a27.5GB磁性（410GB）注意：我们实验中使用的SSD是配置的3,000 IOPS SSD，所有客户端都配备了Moderate网络（测试为82MB/s）和Ubuntu 14.04 LTS（PV）。表II.Amazon EC2上的磁性与SSDzzzzz速度尺寸zzzz磁SSD读写读写1KB2.13MB/s0.77MB/s2.7MB/s1.24MB/s4KB6.70MB/s3.13MB/s10.57MB/s5.67MB/s16KB6.80MB/s4.60MB/s34.87MB/s10.65MB/s64KB7.36MB/s10.67MB/s62.00MB/s28.48MB/s256KB17.36MB/s17.46MB/s58.24MB/s86.63MB/s1MB38.33MB/s22.38MB/s58.24MB/s82.71MB/s4MB61.59MB/s23.20MB/s58.06MB/s82.72MB/s16MB58.12MB/s22.66MB/s58.12MB/s82.92MB/s3.1. 主要实验平台云存储服务：我们的实验在Amazon Simple Storage Services（S3）上进行。作为代表性的云存储服务，Amazon S3被广泛采用作为消费者和商业服务中的基本存储层（例如，Netflix 和EC2 ）。 有些 第三 方云存 储服 务， 比如Dropbox，是 直接 内置 的在S3[Dropbox 2015] 上 。 在 我 们 的 实 验 中 ， 我 们 使 用 了 亚 马 逊 俄 勒 冈 州 数 据 中 心（www.example.com）托管的S3存储系统s3-us-west-2.amazonaws.com云存储客户端：为了在一个稳定且包含良好的系统中运行实验，我们选择Amazon EC2作为我们的客户端平台，从该平台生成云存储I/O流量以运行目标S3存储库。选择AmazonEC2而不是我们自己的机器的一个重要原因是拥有一个量化标准化的客户端，为可重复和有意义的测量提供公开可用的基线为了分析客户端相关因素的影响，我们使用了AmazonEC2实例的五种配置，这些配置在CPU、内存、存储和地理位置方面具有不同的表I显示了这些配置。Baseline客户端位于俄勒冈州，配备两个处理器、7.5GB内存和410GB磁盘存储（表示为Magnetic）。 Magnetic和SSD的速度经过测试，如表II所示。 其他四种配置在不同方面有所不同，特别是CPU，内存，存储和地理位置（在悉尼）。这些不同配置的实例可以很好地满足我们通过“受控比较”来观察云存储性能的需求例如，我们通过比较Baseline客户端和CPU-plus客户端上观察到的性能来研究客户端CPU的影响，因为这两个客户端只有不同的CPU，而其他配置保持不变。换句话说，我们的主要目标不是对特定的云存储客户端进行基准测试;相反，我们更感兴趣的是Baseline客户端和其他比较客户端之间的性能差异。ACM Transactions on Storage，Vol.号132、第十六条，公布日期：2017年5月从客户的角度理解云存储的I/O性能行为十六表III.基于对象的工作负载对象大小对象编号工作负载大小1KB8192080MB4KB40960160MB16KB40960640MB64KB409602，560 MB256KB4096010，240MB1MB1638416，384 MB4MB409616，384 MB16MB204832，768 MB3.2. 附加实验平台上述云存储数据中心和客户端是我们调查不同客户相关因素影响的基本平台。为了验证我们的一些发现，我们进一步在其他数据中心和客户端上部署测试以进行验证。在Amazon存 储 集 群 中 ， 我 们 还 使 用 了 位 于 爱 尔 兰 的 另 一 个 S3 数 据 中 心 （ s3-eu-west-1.amazonaws.com），并在爱尔兰设置了一个EC2客户端（表示为GEO-Ireland）。除了地理位置之外，GEO-Ireland的配置与Baseline客户端相同。此外，位于LSU园区（表示为Local-campus）的客户端也用作Amazon存储集群之外的客户端。该客户端是一个工作站，配备了四核3.2GHz Intel Xeon CPU，8GB内存，910GB磁盘驱动器，1，000Mbps网络连接，并安装了Ubuntu 12.04.5 LTS和Ext4文件系统。磁盘的读取速度测试为167MB/s，顺序访问的写入速度为通过这些额外的测试平台，我们可以以更一般的方式验证我们的发现。3.3. 测试工具和步骤对于我们的实验，我们开发了一个自制的工具，可以灵活地生成不同的工作负载，并直接向S3存储发出原始云存储I/O请求该工具使用S3 API [Boto2015b]，该API基于HTTP并由Amazon提供如前所述，我们有意避免使用POSIX API（例如，S3FS），因为我们的目标是从客户端获得云存储性能的直接视图。某些技术（例如，本地缓存、数据去重、数据压缩）将妨碍我们完整或准确地观察云I/O行为。我们的测试工具使用四个参数生成工作负载：请求类型、请求大小、并行度和对象数量。具体地，请求类型是指PUT或GET（即，上传或下载）;请求大小是指请求的对象的大小;并行度是指并发请求云存储的数量;对象数量是指测试中要请求的对象的数量受限于Amazon S3 API的当前实现[Boto2015a]，我们的测试工具为每个连接生成一个单独对象的上传和下载请求。测试的每次运行由三个步骤组成：（1）生成工作负载和线程池。对于上传和下载测试，我们生成一个大小相同的对象池（由参数请求大小决定）;对象的数量由参数对象编号决定。表III给出了我们的实验中针对不同对象大小使用的工作负载的更多细节。对于上载测试，对象将存储在客户端磁盘上，这意味着必须首先从客户端磁盘读取要上载的每个对象;对于下载测试，对象具有首先作为工作负载存储在云中。请注意，下载测试考虑完整的同步周期，在该周期中，必须首先将对象保存到客户端ACM Transactions on Storage，Vol.号132、第十六条，公布日期：2017年5月十六B. Hou等人持续时间存储，因为大多数云客户端做，导致客户端存储的影响，我们将在后面看到。具体地，每个对象与唯一ID相关联这是因为我们希望使每个请求都是唯一的，避免请求相同对象可能造成的干扰。此外，我们还创建了一个线程池，其中线程的数量由参数parallelism degree决定。(2)发送请求并收集测试结果。在这个步骤中，线程负责并发地发送与对象相关联的请求收集包括每个请求的延迟的测试结果（3）处理收集的测试数据并报告统计数据（例如，平均等待时间和带宽）。我们实验中使用的两个主要指标是延迟和带宽。具体地，延迟是指每个请求的端到端完成时间（即，使用的时间上载/下载单个对象）;带宽指的是在客户端上观察到的总带宽（即，客户端在时间单位内上传或下载的数据总量），计算为 object_size×object_num，其中object_size表示单个对象的大小，object_num表示对象的数量，持续时间表示上传/下载所有对象所花费的时间。在本文中，我们还使用峰值带宽来表示在给定工作负载下在客户机上观察到的最大带宽。3.4. 精度考虑到网络服务和多线程调度可能存在的差异，我们采取了以下措施来保证实验的准确性和可重复性：（1）如前所述，我们定制了Amazon EC2的实例，使其能够作为标准客户端提供稳定的服务，而不是随机挑选一台机器;(2)为了避免实验之间的内存干扰，在每次运行实验之前刷新内存;（3）我们使工作负荷的大小足够大（参见表III），使得每个实验的每次运行持续足够长的持续时间（至少60秒），同时仍然能够在合理的时间范围内完成实验;以及（4）每个实验重复五次，并且我们报告平均值。4. 性能研究为了全面揭示不同因素的影响，我们的测量工作由两部分组成。我们首先进行了一组一般的实验来评估云存储的属性，包括并行度和请求大小。然后，我们重点研究客户端功能的影响，包括CPU，内存，存储和客户端的地理位置我们进一步进行了一组广泛的实验，以揭示混合并行请求之间的干扰的影响，包括混合上传/下载请求和混合小/大请求。4.1. 基本意见存储器的存储效率和请求大小是影响存储性能的两个关键因素.考虑到云存储的并行潜力，我们将并行度设置为64。关于请求大小，先前的工作已经发现，大多数用户请求并不太大[Bocchi et al.2015]，通常小于10MB [Drago et al.2012年]。此外，对于通过互联网传输，大多数云存储客户端将大型请求拆分为较小的请求。例如，Wuala和Dropbox采用4MB块，Google Drive使用8MB块，而OneDrive使用4MB上传和1MB下载[Bocchi et al.2015]。因此，我们将请求大小设置为16MB以研究大小效应。ACM Transactions on Storage，Vol.号132、第十六条，公布日期：2017年5月从客户的角度理解云存储的I/O性能行为十六Fig. 1.基线上的上传/下载带宽。4.1.1. 的影响。I/O并行化对于利用云存储的大规模并行化特性至关重要。在我们的实验中，我们观察到并行性对客户端感知的带宽和延迟并行性对带宽的影响。适当的并行化可以显著提高带宽，而过度并行化可能导致带宽下降。如图1所示，例如，1 KB上传请求的带宽可以提高27倍（从0.025MB/s到0.666MB/s），1 KB下载请求的带宽可以提高21倍（从0.03MB/s到0.634MB/s）。原因有二。一个原因是由于底层的TCP/IP通信协议。 使用TCP/IP，客户端和云必须发送ACK消息以确认数据包传输成功。在高并行度的情况下，由于每个并行请求等待ACK消息所花费的时间重叠，因此多个流可以连续地发送数据。另一个原因是较小的请求通常需要较少的客户端资源，因此客户端可以支持更高的并行度以使流水线饱和，直到并行化的效果受到主要客户端资源之一的限制。另一方面，过度并行化带来的好处越来越少，甚至是负面影响。例如，16MB的上传会因过度并行化而导致轻微的性能下降这与CPU过载时维护线程池的开销有关如观察到的，对于16MB上传，当并行度从一个作业增加到八个作业时，CPU利用率从23%快速增长到几乎100%。在这种情况下，进一步增加并行度将导致性能损失。在后面的部分中，我们将进一步研究CPU的影响并行性对延迟的影响。 适当地并行化云存储I/O可能不会显著影响延迟（即，端到端请求完成时间），而过度并行化可能导致延迟的显著增加。如图2和图3所示，随着并行度的增加，上传和下载请求的平均延迟的增长趋势证实了这一推测。例如，对于4KB的上传请求，当并行度从1增加到16时，平均延迟基本保持不变（约36ms）。当并行度从16增加到64时，平均延迟增加了43%（从36.1ms增加到51.5ms）。 对于大型请求，当并行度超过阈值时，平均延迟线性增加。例如，对于16MB的上传请求，当并行度从4增加到64（16倍）时，平均延迟从1.1s增加到18.3s（17.3倍）。这意味着对于延迟敏感的应用程序，因此，应该小心避免过度并行化（特别是对于大型请求）ACM Transactions on Storage，Vol.号132、第十六条，公布日期：2017年5月十六B. Hou等人图2.基线上的平均上传延迟。图3.基线上的平均下载延迟。图4.基线上具有不同并行度的上传日志的CDF。延迟分布。另一个发现是大请求的延迟分布更加分散，特别是在高并行度下。如图4和图5所示，4KB请求的延迟分布集中在一个很窄的范围内，而4MB请求的延迟分布则分布在一个很宽的范围内。例如，当并行度为64时，4KB上传请求的分布范围为20~200ms，而4MB上传请求的分布范围为200ms~10s。这意味着在并行的情况下，小请求的延迟比大请求的延迟更可预测。ACM Transactions on Storage，Vol.号132、第十六条，公布日期：2017年5月从客户的角度理解云存储的I/O性能行为十六图5.基线上具有不同并行度的下载laundry的CDF。图第六章 在 Baseline上使用ramfs的不同并行度的下载文件的CDF。我们还注意到4MB下载请求的延迟CDF中的这很可能是由于内存刷新行为的干扰造成Linux会定期将内存中的脏数据刷新到外部磁盘。使用较大的内存缓冲区和适度的传入流量，可以快速完成此类异步内存刷新操作，并对前台I/O隐藏当到达速率高于冲洗速率时，这种冲洗操作可能导致这种效果。在这种情况下，由于磁盘速度有限（仅23 MB/秒），低于下载速度（78 MB/秒），客户端内存将很快用完，磁盘刷新时间将反映在关键路径中，并影响用户感知的延迟，从而导致观察到的模式。为了证实这个推测，我们重复了这个实验，用ramfs替换了磁盘，这消除了磁盘瓶颈，我们可以在图6中看到这样的4.1.2. 请求大小的影响。在传统存储中，请求大小对于组织大型和顺序I/O至关重要，并且对于分摊磁盘磁头寻道开销非常重要。在云存储中也观察到了类似的效果。请求大小对带宽的影响。 正如预期的那样，增加请求大小（即，GET/PUT的大小）可以显著地提高带宽，但是当请求大小超过阈值时，所实现的益处减少。如图1（a）和图1（b）所示，大请求和小请求的峰值带宽有很大的差距。例如，4 MB上传请求的峰值带宽是4KB上传请求的23.5倍（58.9MB/s，2.5MB/s）; 4 MB下载请求的峰值带宽是4KB下载请求的10.7倍（28.9MB/s vs.ACM Transactions on Storage，Vol.号132、第十六条，公布日期：2017年5月十六B. Hou等人×2.7MB/s).造成这种现象的原因有几个。原因之一是客户端存储上较大的I/O请求通常比较小的I/O请求具有更高的I/O速度(see表II）。另一个原因是，由于数据包级并行性，较大的请求通过网络传输数据的效率更高[Huan 2002]。此外，较大的请求大小可以更好地分摊相关开销。类似于并行化的效果，由于其他因素的限制，增加请求大小不能带来无限的带宽增加。例如，客户端存储的速度是有限的。下载的对象需要首先从本地设备读取，下载的对象需要写入本地设备。如表II所示，当请求大小从4 MB增长到16 MB时，Magnetic的速度略有提高，这限制了客户端的I/O速度此外，TCP窗口的最大大小是有限的，尽管是可调的[Amazon 2015 d; Jacobson et al. 1992]。当请求大小超过某个阈值时，增加请求大小所带来的好处就会减少。此外，其他因素，如路由上的链路带宽、云端的处理速度等，也会限制可实现的所有这些观察都表明，通过增加请求大小获得的好处是显著的，但不是无限的。请求大小对延迟的影响。 增加请求大小和并行化小请求都可能导致延迟增加。 例如，如图2和图3所示，当并行度为1时，4MB下载请求的平均延迟为192ms，是1MB下载请求（33ms）的5.8倍。然而，当考虑到并行度时，情况就不同了。例如，并行度为1的4MB下载请求的平均延迟为192 ms，比并行度为64的1MB下载请求的平均延迟（2.9s）低13.8倍。因此，如果不考虑由过parallelization引起的延迟增加，则难以断言较大的请求意味着较长的延迟。对于小的请求，即使在相同的并行度下，延迟也不一定随着请求大小的增加而增加。图2（a）显示了1KB和4KB上传请求的平均延迟几乎相同。类似地，在图3（a）中，我们发现1KB、4KB和16KB下载请求的平均延迟几乎相等。请求延迟主要由三部分组成：通过网络的数据传输时间、客户端I/O时间和其他处理时间。对于小请求，数据传输时间只占总延迟的一小部分，而其他两个主要部分基本保持不变，这使得小请求的延迟相似。此外，由于最大TCP窗口默认为64KB，考虑到网络的并行性[Huan2002]，小于64KB的数据的传输时间应该是相似的。4.1.3. 重复性与请求大小。在前面的章节中，我们发现增加并行度或增加请求大小都可以有效地提高带宽，但两者都有局限性。这里自然会出现一个有趣的问题：是否存在并行度和请求大小的组合来实现最佳性能？探讨这一问题具有现实意义。考虑以下情况：如果我们有一个4MB的对象要上传，我们可以选择通过单个线程上传它，或者将它分成四个1MB的块并并行上传。哪个更快？图7显示了并行度和请求大小的不同组合下的性能。显然，256 KB 16的带宽最高（44.2MB/s），约为最低（14.5MB/s）的3倍这表明存在适当的组合，并且可以实现最佳性能。这一观察结果证实，适当地结合请求大小和并行度可以充分提高带宽，而不仅仅是优化一个维度。ACM Transactions on Storage，Vol.号132、第十六条，公布日期：2017年5月从客户的角度理解云存储的I/O性能行为十六× ××图7.在基线上上传不同组合的带宽。我们还发现，在某些情况下，无论是增加并行度或增加请求大小相同的因素可以实现相同的带宽改善。例如，对于上载请求，1 KB 16、4KB 4和16 KB 1具有相似的带宽（0.4MB/s）。这里有另一个实际问题：如果我们有一组小文件（例如，1KB），我们是否应该采用高并行度（例如，16）或将小文件捆绑在一起以创建更大的请求大小（例如，16KB）？从提高带宽的角度来看，高并行度或大请求大小都是可行的。然而，从客户端资源利用率的角度来看，我们发现大的请求大小需要更少的CPU资源。 通过Linux中的vmstat，我们发现CPU前三种情况的利用率分别为65%、15%和5%这表明对于可以实现相当带宽的组合，较大的请求大小消耗较少的CPU资源。这是因为对于更大的请求大小，必须维护更少的线程来实现类似的带宽，从而降低了CPU利用率。4.1.4. 补充说明。为了进一步验证我们的发现，我们还重复了两个额外的实验设置相同的实验。我们首先在GEO-Ireland客户端上重复了实验，该客户端的配置与基线客户端相同，并 访 问 Amazon 的 爱 尔 兰 数 据 中 心 （ s3-eu-west- www.example.com ） 中 的 S3 存 储1.amazonaws.com 我们在使用Local-campus客户端的实验中也获得了类似的在第4.2节和第4.3节中，我们将进一步研究客户端的能力和地理距离如何摘要：在本节中，我们将研究并行性和请求大小对客户端上观察到的云存储访问延迟和带宽类似于一些先前的工作（例如，Ou et al. [2015]），我们发现并行性和请求大小对云存储的感知性能很重要，并且还有其他一些有趣的发现。例如，小请求的访问权限（例如，小于64 KB）的访问速度相当;并行化可能会使访问延迟更加不可预测。另一个实际有用的发现是，并行度和请求大小的适当组合基于这一观察，我们还在第5节中提出了一种基于抽样和推理的方法来决定适当的组合。4.2. 客户端能力与传统存储不同，云存储客户端非常多样化。在本节中，我们将研究影响客户端处理云存储I/O的能力的不同因素我们比较了三种不同的ACM Transactions on Storage，Vol.号132、第十六条，公布日期：2017年5月十六B. Hou等人图8.峰值带宽比较（基线与CPU+）。客户端，包括CPU+、STOR-ssd和MEM-minus，基线，以揭示每个因素的影响。4.2.1. 客户端CPU的影响。在云存储I/O中，客户端CPU负责发送/接收数据包和客户端I/O。在本节中，我们通过比较Baseline（两个CPU）和CPU-plus（四个CPU）的性能来研究客户端CPU的影响。客户端CPU对