ACM通信
贡献的文章
杀手微秒的攻击
图片来源:Peter Crowther Associates
今天我们使用的计算机系统使得程序员可以很容易地减少纳秒和毫秒级的事件延迟(例如几十或几百纳秒级的DRAM访问和几毫秒级的磁盘I/ o)，但严重缺乏对微秒级事件的支持。对于仓库级计算机编程来说，这种疏忽正迅速成为一个严重的问题，从数据中心网络到新兴内存，高效地处理微秒级事件正成为新一代低延迟I/O设备的关键(参见第一个侧栏“微秒是否得到足够的尊重?”)。
关键的见解
处理器设计者开发了多种技术，通过为内存系统提供一个简单的同步编程接口，来促进在纳秒级别上工作的深层内存层次结构。加载操作将在逻辑上阻塞线程的执行，程序在加载完成后似乎会恢复。大量复杂的微架构技术使得高性能成为可能，同时支持这种直观的编程模型。技术包括预取、乱序执行和分支预测。由于纳秒级的设备非常快，底层的交互主要由硬件来完成。
在减缓延迟的光谱的另一端，计算机科学家已经研究了许多技术——典型的是基于处理毫秒时间尺度的软件。操作系统上下文切换是一个显著的例子。例如，当aread ()当系统调用磁盘时，操作系统启动低级的I/O操作，但也执行软件上下文切换到不同的线程，以在磁盘操作期间使用处理器。原线程在I/O完成后的某个时间恢复执行。进行一次磁盘访问的开销(毫秒)很容易超过两次上下文切换的开销(微秒)。毫秒级的设备速度非常慢，因此这些基于软件的机制的成本可以摊销表1)．
这些用于与纳秒级和毫秒级设备交互的同步模型比异步模型更容易。在异步编程模型中，程序向设备发送请求并继续处理其他工作，直到请求完成。为了检测请求何时完成，程序必须定期轮询请求的状态或使用中断机制。我们在谷歌的经验使我们强烈倾向于同步编程模型。同步代码要简单得多，因此更容易编写、调优和调试(请参阅第二侧栏“同步/异步编程模型”)。
当一个典型的端到端应用程序可以跨越多个紧密交互的小型系统时，同步编程模型的好处会在规模上得到进一步放大，这些系统通常是跨几种语言编写的——esc、c++、Java、JavaScript、Go等等，这些语言都有自己不同的、不断变化的异步编程习惯。2，11在代码库中使用简单一致的api和习惯用法可以显著提高软件开发的生产力。作为谷歌中同步编程模型总体好处的一个说明文示例，是对Colossus的重写6使用带有轻量级线程的同步I/O模型的客户端库在性能上获得了显著的改进，同时使代码更紧凑、更容易理解。然而，更重要的是，将管理异步事件的负担从程序员转移到操作系统或线程库，使代码大大简化。这种转移在仓库规模的环境中是非常重要的，在这种环境中，代码库由数千名开发人员接触，每周发布多次重要的软件。
最近的趋势指向了一种新的低延迟I/O设备，它既不会在毫秒级工作，也不会在纳秒级工作。考虑数据中心网络。40Gbps的全尺寸数据包的传输时间小于1微秒(300ns)。以光速，穿越一个典型数据中心的长度(例如，200米到300米)的时间大约为一微秒。因此，快速数据中心网络可能具有微秒量级的延迟。同样，原始闪存设备的延迟是几十微秒量级。新兴的非易失性存储器技术(如Intel-Micron Xpoint 3D存储器)的潜在潜力9和莫内塔3.)也有望达到微秒级的低端。内存系统(如斯坦福RAMCloud)14项目)还估计了微秒量级的延迟。细粒度GPU卸载(以及其他加速器)具有类似的微秒级延迟。
不仅微秒级的硬件设备变得可用，我们还看到了利用低延迟存储和通信的日益增长的需求。一个关键原因是登纳德缩放法的消亡和摩尔定律在2003年的放缓，这结束了微处理器性能的快速提升;现在的处理器速度要比每18个月翻一番的速度慢大约20倍。8作为回应，为了增强在线服务，云计算公司增加了用于客户查询的计算机数量。例如，单用户搜索查询已经转化为数千个远程过程调用(rpc)，这个数字在未来还会增加。
优化为纳秒或毫秒时间尺度的技术不能很好地扩展到微秒范围。用于纳秒时间尺度的超标量乱序执行、分支预测、预取、同步多线程和其他技术不能很好地扩展到微秒范围;系统设计人员没有足够的指令级并行性或硬件管理的线程上下文来隐藏较长的延迟。同样地，容忍毫秒级延迟的软件技术(如软件导向的上下文切换)也难以缩小到微秒级;这些技术中的开销通常等于或超过I/O设备本身的延迟。正如我们将看到的，采用高速硬件并抛弃其性能而使用为毫秒级设备设计的软件是非常容易的。
如何浪费快速数据中心网络
为了更好地理解优化如何以微秒为目标，可以考虑一个高性能网络。图1是一个说明性的例子，说明了一个2s的fabric如何通过累积的软件开销，变成一个接近1000s的数据中心fabric。每个度量都反映了往返延迟的中值(来自应用程序)，没有排队延迟或未加载延迟。
在快速数据中心网络中，一个非常基本的远程直接内存访问(RDMA)操作大约需要2秒。RDMA操作将操作处理和传输可靠性的机制卸载到专门的硬件设备。使它成为一个“双面”原语(涉及远程软件而不仅仅是远程硬件)多增加了几微秒。将网络线程的开销分配给操作线程(在不同的处理器上)进一步增加了由于处理器唤醒和内核调度器活动造成的延迟。使用基于中断的通知而不是自旋轮询会增加更多的微秒。添加一个充满功能的RPC堆栈会产生超过几十微秒的软件开销。最后，使用成熟的TCP/IP堆栈而不是基于rdma的传输增加的最终开销在这个特定的实验中超过了75s。
此外，还有其他更不可预测、更非直观的开销来源。例如，当RPC到达一个核心处于睡眠状态的服务器时，可能会产生额外的延迟，通常是几十到几百微秒，以摆脱睡眠状态(并可能激活处理器缓存)。同样，各种机制(如处理器间中断、数据复制、上下文切换和核心跳转)都会增加开销，同样是微秒级的。我们还测量了标准谷歌调试特性将延迟降低了至多几十微秒。最后，主机、应用程序和网络结构中的排队开销都可能导致额外的延迟，通常为几十到几百微秒。其中一些开销来源对尾延迟的影响比对中值延迟的影响更严重，这在分布式计算中可能特别有问题。4
对于新的非易失性存储器的开销也可以做类似的观察。例如，Moneta项目3.在加州大学圣地亚哥分校(University of California, San Diego)，他讨论了基线原始访问延迟几微秒的非易失性内存的访问延迟是如何由于内核、中断处理和数据复制之间的不同开销而增加几乎5倍的。
系统设计者需要在微秒挑战的背景下重新思考硬件和软件堆栈。系统设计决策，如操作系统管理的线程和基于中断的通知，在毫秒级的设计中被忽略，现在必须更仔细地重新设计，系统优化(例如明确针对毫秒级的存储I/O调度器)必须重新考虑微秒级。
如何浪费快速数据中心处理器
微秒级事件的另一个显著负面影响是对处理器效率的影响。如果我们根据请求流的吞吐量(每秒请求数)来衡量处理器资源效率，一个简单的排队理论模型会告诉我们，随着服务时间的增加，吞吐量会下降。在微秒状态下，当服务时间主要由“开销”而不是有用的计算组成时，吞吐量会急剧下降。
说明了效果,图2在y轴上显示效率(已实现吞吐量与理想吞吐量的比例)，在x轴上显示服务时间。不同的曲线显示了改变“微秒开销”值的影响;也就是说，花费在每个开销事件上的时间数量，标有“无开销”的线代表一个假设的理想系统，开销为零。该模型假设一个简单的封闭排队模型，具有确定的到达和服务时间，其中服务时间表示开销事件之间的时间。
正如预期的那样，对于较短的服务时间，仅一微秒的开销将导致总体吞吐量效率的显著降低。在现实世界中，这么短的服务时间有多大可能?表2列出了生产web搜索工作负载的服务时间，在适当调优工作负载时，度量I/O事件之间的指令数量。当我们转向使用快速闪存或新的非易失性存储器的系统时，预计服务时间在0.5s到10s之间。微秒的开销会显著降低这种情况下的性能。
在较长的服务时间下，亚微秒的开销是可以容忍的，吞吐量接近理想状态。几十微秒的较高开销(可能来自于前面详细介绍的软件开销)可能会导致性能下降，因此系统设计人员仍然需要针对致命微秒进行优化。
其他开销超出了访问微秒级设备的基本机制。2015年的一篇论文总结了谷歌多年的纵向研究10显示了20%-25%的全舰队处理器周期花费在我们称为“数据中心税”的低级管理费用上。示例包括数据的序列化和反序列化、内存分配和分配、网络堆栈成本、压缩和加密。数据中心税增加了致命的微秒挑战。一个合乎逻辑的问题是，系统设计者是否可以通过将部分开销转移到单独的核心或加速器来解决降低的处理器效率。不幸的是，在个位数微秒的I/O延迟下，I/O操作往往与处理器上的主要工作紧密耦合。
正是这些处理器开销的这种频繁和紧密耦合的特性更加重要，就像在“千刀致死”中那样。例如，如果很少执行微秒级的操作，则可能不需要考虑保持处理器性能。应用程序线程只需忙轮询来等待微秒操作完成。或者，如果这些操作与处理器上的主要计算没有紧密耦合，则可以使用传统的卸载引擎。然而,鉴于精密而且紧密耦合的开销，在处理器微架构级别需要新的硬件优化，以重新考虑构成未来微秒级I/O事件的这些核心功能的实现和调度。
解决方案的方向
这些证据表明，在即将到来的“致命的微秒时代”中，有几类主要的机会。首先，也是更短期的，通过逐步添加未针对如此小的延迟进行调优的次优支持软件，很容易浪费微秒设备的所有好处。因此，计算机科学家需要设计“微秒感知”的系统堆栈。他们还需要在过去五年该领域的相关工作(如Caulfied等人，3.Nanavati et al .,12和Ousterhout等人。14)继续重新设计传统的低级别系统优化，减少锁争用和同步，降低中断处理开销，在旋转轮询期间有效利用资源，改进作业调度和硬件卸载但是对于微秒制度。
高性能计算行业长期以来一直在处理低延迟网络。然而，在超级计算机中使用的技术并不直接适用于仓库规模的计算机表3)．首先，高性能系统的工作负载变化较慢，需要接触代码的程序员较少。因此，代码的简单性和最大的程序员生产力并不像Amazon或谷歌那样至关重要，因为在这些公司，关键软件产品每周发布多次。高性能工作负载还往往具有更简单的静态数据结构，这有助于实现更简单、更快的网络连接。其次，重点主要是性能(与大规模Web部署中按总拥有成本计算的性能相比)。因此，当阻塞mpi风格的集合消息时，它们可以使处理器高度未被利用。相比之下，仓库规模的计算系统的一个关键重点是需要优化低延迟，同时实现更高的利用率。
如前所述，用于隐藏延迟的传统处理器优化耗尽了指令级管道并行性以容忍微秒延迟。系统设计人员需要新的硬件优化，以将同步阻塞机制和线程级并行的使用扩展到微秒范围。
上下文切换可以提供帮助，尽管代价是增加功率和延迟。先前的快速上下文切换方法(如Denelcor HEP15和Tera MTA电脑1)以单线程性能为代价，放弃了本地和私有高级缓存带来的延迟优势，因此在更广泛的仓库级计算环境中吸引力有限，在这种环境中，程序员希望容忍微秒事件、低开销和易于编程。一些语言和运行时(如Go和Erlang)以轻量级线程为特色5，7减少与操作系统线程相关的内存和上下文切换开销。但是当处理I/O时，这些系统又回到了更重量级的机制。例如，Grappa平台13为小消息构建高效的任务调度器和通信层，但可以权衡更受限制的编程环境和较低效率的性能，还可以优化吞吐量。需要新的硬件思想以极快的延迟(几十纳秒)实现在大量线程(每个处理器数十到数百个线程，但找到最佳点是一个开放的问题)之间的上下文切换。
还需要硬件创新来帮助协调与挂起I/O的通信、高效的队列管理和任务调度/分派，以及跨多个上下文更好的处理器状态(如缓存)管理。理想情况下，未来的调度器将对I/O提供丰富的支持(例如能够基于多个I/O操作的就绪状态来驻留线程)。例如，类似于x86 monitor/mwait指令的设施一个可以让线程屈服，直到I/O操作以非常低的开销完成。同时，硬件可以无缝地调度不同的线程。为了进一步减少开销，一个潜在的硬件实现可以将线程的上下文缓存到现有的L1/L2/L3层次结构中或一个特殊用途的上下文缓存中。硬件中改进的资源隔离和服务质量控制也会有所帮助。对构建跟踪微秒开销的新仪器的硬件支持也很有用。
最后，支持微秒级设备的技术不一定要使处理器管道保持繁忙。一种有前途的解决方案可能是，当一个微秒级的访问处于突出状态时，使处理器停止消耗能量，并将该能量转移到其他访问时没有阻塞的核心。
结论
系统设计人员不能再忽视对微秒级I/O的有效支持，因为最有用的新仓库级计算技术开始在这个时间尺度上运行。今天的硬件和系统软件构成了一个不充分的平台，特别是考虑到对同步编程模型的支持被认为是软件生产力的关键。需要新的微秒优化的系统堆栈，重新检查有关适当的分层和抽象、控制和数据平面分离以及硬件/软件边界的问题。这种微秒级的优化设计，以及相应的更快的I/O，反过来可以促进利用低延迟通信的新应用程序和编程模型的良性循环，极大地提高仓库级计算机的有效计算能力。
致谢
我们要感谢Al Borchers、Robert Cypher、Lawrence Greenfield、Mark Hill、Urs Hölzle、Christos Kozyrakis、Noah Levine、Milo Martin、Jeff Mogul、John Ousterhout、Amin Vahdat、Sean Quinlan和Tom Wenisch对本文的详细评论。我们还感谢谷歌的团队，他们构建、管理和维护系统，为我们在这里探索的见解做出了贡献。
参考文献
1.阿尔弗森，R.等人。Tera计算机系统。在第四届超级计算国际会议论文集(荷兰阿姆斯特丹，1115年6月)。ACM出版社，纽约，1990,16。
2.提高c++库。提高asio库;http://www.boost.org/doc/libs/1_59_0/doc/html/boost_asio.html
3.考尔菲尔德等人。用于下一代非易失性存储器的高性能存储阵列架构。在2010年IEEE/ACM微架构国际研讨会论文集(乔治亚州亚特兰大，12月48日)。IEEE计算机学会出版社，2010。
4.迪恩，j和巴罗佐，洛杉矶，大规模的尾巴。Commun。ACM 56， 2(2013年2月)，7480。
5.Erlang。Erlang用户指南8.0版本。流程；http://erlang.org/doc/efficiency_guide/processes.html
6.存储架构和挑战。在2010年谷歌教师峰会会议记录(加州山景城，2010年7月29日);http://www.systutorials.com/3306/storage-architecture-and-challenges/
7.Golang.org。有效的去。了goroutine;https://golang.org/doc/effective_go.html#goroutines
8.亨尼斯和帕特森。计算机体系结构:定量方法，第六版。爱思唯尔，剑桥，MA, 2017。
9.英特尔编辑部。2015年7月28日，英特尔和美光公司生产突破性内存技术;http://newsroom.intel.com/community/intel_newsroom/blog/2015/07/28/intel-and-micron-produce-breakthrough-memory-technology
10.Kanev, S.等。分析一个仓库规模的计算机。在42人会议记录nd计算机体系结构国际研讨会(俄勒冈州波特兰，1317年6月)。ACM出版社，纽约，2015年。
11.微软。使用Async和Await进行异步编程(c#和Visual Basic)；https://msdn.microsoft.com/en-us/library/hh191443.aspx
12.纳纳瓦蒂，M.等。非易失性存储:数据中心转移中心的含义。Commun。ACM 501(2016年1月)，5863。
13.Nelson, J.等。容忍延迟的软件分布式共享内存。在USENIX年度技术会议论文集(Santa Clara, CA, 810年7月)。Usenix协会，伯克利，加州，2015年。
14.Ousterhout, j等人。RAMCloud存储系统。ACM计算机系统汇刊， 3(2015年9月)，7:17:55。
15.流水线共享资源MIMD计算机。一章高级计算机体系结构。D.P. Agrawal, Ed. IEEE计算机协会出版社，Los Alamitos, CA, 1986, 3941。
16.Wikipedia.org．谷歌语法观众;https://en.wikipedia.org/wiki/Google_Ngram_Viewer
数据
图1。累积的软件开销，都在微秒范围内，会使性能下降几个数量级。
数字观看作者在此独家讨论他们的工作通信视频。//www.eqigeno.com/videos/the-attack-of-the-killer-microseconds
表
表2。服务时间度量I/O事件之间的指令数量，用于生产质量调优的web搜索工作负载。flash和DRAM数据是为实际生产使用而测量的;新内存/存储层的粗体数据基于详细的跟踪分析。
表3。比较高性能计算和仓库规模的计算系统。虽然高性能计算系统通常针对低延迟网络进行优化，但它们的设计和技术并不直接适用于仓库规模的计算机。
数字ms, s和ns的N-gram查看器。侧栏:同步/异步编程模型
同步api维护顺序执行的模型，线程的状态可以存储在堆栈上，而不需要应用程序显式地管理。这将导致代码更短、更容易理解、更容易维护，甚至可能更高效。相比之下，在异步模型中，每当操作被触发时，代码通常必须被分割并移动到不同的函数中。控制流变得模糊，管理运行到完成的异步事件处理函数之间的状态变成了应用程序的责任。
考虑一个简单的例子，其中函数返回给定文档标识符中出现的单词数，实现可以将缓存的文档存储在微秒级的设备上。第一个代码部分中的示例对微秒级设备进行了两次同步访问:第一次检索文档的索引位置，第二次使用该位置检索实际文档内容以统计单词。使用同步编程模型，它不仅简单，而且通过提供具有熟悉语法的自然的同步CountWords函数，该模型还可以完全抽象出设备访问。
第二个代码部分中的c++ 11示例展示了一个异步模型，其中使用了“回调”(通常称为“延续”)。当异步操作完成时，事件处理循环调用回调以继续计算。由于执行了两个异步操作，因此需要两个回调。此外，CountWords API现在本身必须是异步的。与同步示例不同的是，异步操作之间的状态必须显式地在堆上管理和跟踪，而不是在线程堆栈上。
回调使控制流显式显示，而不是仅仅调用函数并等待它完成。虽然语言和库可以在一定程度上简化回调和延续的使用(例如支持async/await、lambdas、任务和future)，但结果仍然是比简单的同步函数调用模型更混乱、更难以理解的代码。
在这个异步示例中，将代码包装在同步CountWords()函数中，以便抽象出底层异步微秒级设备的存在，这需要对等待原语的支持。现有的等待条件的方法调用了操作系统对线程调度的支持，因此当等待时间达到微秒级时，会产生很大的开销。
数字图书馆是由计算机协会出版的。版权所有©2017 ACM, Inc.
没有发现记录