OSDI摘要中文翻译.docx
《OSDI摘要中文翻译.docx》由会员分享，可在线阅读，更多相关《OSDI摘要中文翻译.docx（11页珍藏版）》请在冰豆网上搜索。
OSDI摘要中文翻译
OSDI2010摘要中文翻译
一、Comet:
Anactivedistributedkey-valuestore[Comet：
一种主动分布式的键-值存储]
分布式键-值存储系统被广泛的应用在企业和互联网上。
我们的研究通过特定应用制定来寻找大幅度提高键-值存储系统应用空间的方法。
我们设计实现了一个网络（Comet）——一个可扩展的键-值分布式存储系统。
每个网络节点存储了一组主动存储对象（ASOs），这些对象包含了一个键，一个值以及一系列的处理程序。
Comet处理程序运行返回定时器或者存储操作的结果，比如get和put，这样它就允许一个主动存储对象执行动态的，针对特定应用的动作来自定义自己的行为。
处理程序都是用简单的具有沙箱扩展型的语言编写，以此提供安全和独立的特性。
我们为Vuze（开发小组，开发了JavaTorrent客户端，支持I2P和Tor匿名网络协议）DHT（DistributedHashTable分布式哈希表）
实现了一个Comet原型，在PlanetLab（新一代互联网，计算服务“覆盖网络”）将网络节点部署在Vuze上，并创建了许多的Comet应用。
实验结果证明简单性，安全性和受限制的扩展性可以大幅度提高分布式主动存储系统应用的能力。
这项研究通过各种需求的应用证明了该研究有利于单一存储系统的共享，并且能加强如今巨型云的内部效率。
二、Depot:
Cloudstoragewithminimaltrust[Depot：
基于最小信任的云存储]
该论文介绍了一种基于最小信任假设的云存储系统的设计、实现和评估。
Depot系统即使在经受了大量的客户端和服务器的漏洞和恶意的测试下，也能为正确的客户提供安全性和现场的保证。
这种保证来自Depot使用了两层架构。
首先，Depot保证由正确节点发现的更新能固定的遵守FJC（Fork-Join-Causal）一致性。
FJC是在有错误节点的情况下也能保持安全性和现场性的因果一致性的一种轻度削弱。
其次，Depot实现了一种使用这些一致更新规则提供合适的一致性、疲劳性、持久性和恢复性的协议。
我们的评估证明了提供这些保证的代价是可以接受的，并且即使在重大错误发生时，Depot可以承受错误，保持良好的可用性，等待性，间接性，和疲劳性。
[注*因果一致性：
假设进程P1写变量x，然后P2读出x，写入y。
这里读出x和写入y之间可能有潜在的因果联系，因为y的计算很可能决定于P2读到的x值（即P1写入的值）]
三、SPORC:
GroupCollaborationusingUntrustedCloudResources[SPORC:
使用不可信任云资源的组协作]
对于面向用户的应用，比如文字处理软件和日历软件，云服务是一种很具有吸引力的部署模型。
不同于桌面应用，云服务允许多个用户同时和实时的编辑共享的状态，从而使得它变得可扩展性，高可用性和全局访问性。
不幸的是，这些利处是基于信赖云提供商通过提供潜在敏感和重要的数据的代价实现的。
为了克服这种严格的权衡，我们提出了SPORC，一种使用不可信任的服务器来构建各种协作应用的通用框架。
在SPORC里，服务器只能看到加密后的数据而且一旦偏离正确的执行就会被发现。
SPORC支持同时的低延迟的编辑共享状态，允许离线操作，支持并发状态下的动态访问控制。
我们使用两个原型应用来证明SPORC的灵活性：
一个是因果一致性的键值存储系统和一个基于浏览器协作的文本编辑器。
概念上，SPORC说明了操作转换（OT，operationtransformation）和分支一致性（forkconsistency）的互补利益。
前者允许SPORC客户端在不带互斥琐的前提下执行同时操作来自动解决结果冲突。
后者可以阻止不正常行为的服务器执行模棱两可的操作顺序，除非它想把用户分为不相交的集合。
值得注意的是，不想以前的系统，SPORC可以自动从通过利用操作转换（OT）的冲突解决机制进行恶意的分支操作中恢复。
四、AdHocSynchronizationConsideredHarmful[点对点模式被认为是有害的]
许多在现有的多线程程序中的同步操作是通过点对点模式[AdHot]来实现的。
本文的第一部分针对并行程序的同步的特性做了全面的研究。
通过对12个各种各样程序（服务器程序，桌面程序，科学计算程序）的299Adhot同步操作的研究，包括Apache，MySQL，Mozilla等等，我们发现一些有趣的有可能带有警告意味的特点：
（1）每个研究的应用都使用了AdHoc操作。
尤其是，每个程序中有6-83不等的AdHoc同步操作。
（2）AdHoc的同步操作是容易出错的。
显著比例（22-67%）的AdHoc同步操作产生了bug和严重的性能问题。
（3）AdHoc的同步操作的实现是多种多样的，而且之间许多同步不能被简单的认为是同步，缺乏可读性和可维护性。
我们的第二部分工作创建了一个名字叫同步发现器（SyncFinder）的工具去自动识别和注解用C/C++书写的并发程序的AdHoc同步操作来帮助程序员把他们的代码移植到更好的结构实现中，然而同时也能允许其他工具能识别出程序中的同步操作。
通过对25个并发程序的评估显示，平均来看，SyncFinder能自动识别出96%的AdHoc同步操作，误报率是6%。
我们也构造了两个用例来利用SyncFinder的自动注解功能。
第一个例子使用注解工具检测到5个死锁（包括两个新的死锁）和16个潜在的问题，而这些问题是以往的工具比如Apache，MySQL，Mozilla发现不了的。
第二个例子将Valgrind的数据竞争检查的误报率降低了43-86%。
[*注：
Valgrind：
一款用于内存调试、内存泄漏检测以及性能分析的软件开发工具]
五、BypassingRacesinLiveApplicationswithExecutionFilters[使用执行过滤器绕过现场应用的冲突]
部署多线程的应用包含许多冲突，因为这些应用很难书写，测试和调试。
糟糕的是，在部署程序中冲突数量可能会大幅度增加，原因在于多核的硬件和目前冲突探测器的不成熟。
LOOM是一种“现场解决”的系统，它被设计成在执行时快速安全的绕过应用程序的冲突。
LOOM为开发者提供了一个灵活的和安全的语言来书写执行过滤器（ExecutionFilters）来明确地同步代码。
它使用一种评估算法安全的安装该过滤器到现场应用中来避免冲突。
它通过混合检测（把静态的和动态的检测相结合）来降低性能的开销。
我们从六个应用组成的多样集合中使用9个真正的冲突来对LOOM进行评估，包括MySQL和Apache。
实验结果显示：
（1）LOOM能及时的安全修复所有已经评估过的冲突，从而增强了应用的可用性；
（2）LOOM需要很小的性能开销；（3）LOOM能随着应用线程数量的增加有很好的扩展性；（4）LOOM使用方便。
六、EffectiveData-RaceDetectionfortheKernel[针对内核的有效数据冲突检测]
数据冲突是当两个线程在没有合适的同步下错误的访问同一块共享的存储位置时产生的一类重要的并发错误。
本文展示了DataCollider（数据对撞,DC），使用轻量级的有效的技术来探测内核模块的数据冲突。
不像已有的数据冲突探测技术，DC忽略程序使用同步协议（比如琐原则）来保护共享内存的访问。
这一点对于使用了无数复杂的针对特定架构和设备的同步机制的底层内核代码尤为重要。
为了降低运行时开销，DC随机的抽取了一小部分内存访问作为数据冲突的代表。
DC的关键新颖之处是它使用已经被许多硬件体系结构支持的断点机制来实现很小的运行时开销。
我们已经为Win7的内核实现的DC，并发现了25个已经确认的数据访问冲突，而其中的12个已经被修复了。
七、DeterministicProcessGroupsindOS[磁盘操作系统的确定性程序组]
目前多处理器系统以不确定的方式执行并行和并发的软件程序：
即使精确地给定相同的输入，相同的程序的两次执行也可能产生不同的结果。
这使得调试，测试和自动容错复制更加的复杂。
过去把解决问题的努力主要集中在记录和重现上，但是将执行过程确定化可以从根本上解决这个问题。
我们工作的目标有两个方面：
（1）把任意的，不可修改的多线程的程序充分确定的执行作为操作系统的服务。
（2）将所有故意不确定的来源，比如网络IO接口转换为明确的和可控的。
为此，我们提出了一个新的操作系统抽象，DPG（DeterministicProcessGroup）。
所有内部的进程和线程之间的通信对于DPG来说发生是确定的，包括通过共享内存访问、操作系统通道（比如管道，信号量，文件系统）的通信。
为了解决外部事件的根本不确定性，我们抽象出一个垫片层（shimlayer），一个嵌入在所有在DPG和外部世界交互之间的可编程的接口，使得确定性对反应性的应用尤为有用。
我们把DPG抽象实现为Linux的扩展并使用三个用例证明它的有效性：
纯精确的执行；可复制的执行；通过对外部输入做日志实现记录和重现。
我们在并行和反应性的例子中评估了系统的实现，包括Apache，Chromium和PARSEC。
八、EfficientSystem-EnforcedDeterministicParallelism[有效的强制系统确定性并行]
确定性执行为调试，容错和安全性提供了很多的方便。
然而，目前针对并行程序确定性执行的方法通常需要很高的开销，会使得不正当行为的软件击败可重复性，还使得依赖于时间的冲突转化成依赖于输入和路径的冲突，而不是去消除这些冲突。
我们提出了一个并行程序模型来解决这些问题，并使用Determinator，一个概念证明型的操作系统，来证明模型的实用性。
Determinator的微内核API仅仅提供“无共享”（shared-nothing）的地址空间和确定性的进程间通信原语来保证非特权代码——不管是正常行为的还是不正常行为的代码——都能重复精确的执行。
在微内核之上，Determinator的用户层运行时适应乐观的重现技术为了向线程和进程级的并行程序提供私有工作区模型。
这种模型避免了读/写数据冲突的产生，而且把写/写冲突转化为可靠检测的冲突。
粗粒的并行基准在执行和扩展在多核PC和集群系统的交叉节点上对于非确定的系统是对等的。
九、StableDeterministicMultithreadingthroughScheduleMemoization[利用调度记忆的可靠确定多线程技术]
确定的多线程系统（DMT）消除了线程调度中的不确定性，简化了多线程程序的开发。
然而，已有的DMT系统都是不稳定的；即使因为细微的输入和执行环境的差别，它们也会强制程序冒险进入大不相同的调度程序中，这样就破坏了确定性的优势。
更甚，现有的DMT系统几乎不和输入连续不确定到达的服务程序一起工作。
TERN是一个稳定的DMT系统。
TERN最大的亮点是调度记忆的创意，就是存储过去工作调度的信息并把它们重复利用在将来的输入上，使得程序在不同输入下的行为保持稳定。
TERN的第二个亮点是窗口化（windowing）的创意，就是针对服务程序扩展了调度记忆算法，通过将连续的请求流分割成一系列的请求窗口。
我们的TERN在Linux上实现运行。
它作为用户空间的调度器运行，不会对操作系统做任何改变并且仅仅对应用程序做若干行变化。
我们使用真实综合的工作负载在14种不同的程序上对TERN进行测试。
结果证明TERN简单易用，让程序更加确定和稳定，并且有合理的开销。
十、AvailabilityinGloballyDistributedStorageSystems[全局分布式存储系统的可用性]
高可用性的云存储系统通常是用复杂的构建在商业服务器和磁盘驱动集群顶端的多层分布式系统实现的。
因此需要复杂的管理、负载均衡、恢复技术来实现在各种各样的错误源（包括软件、硬件、网络连接以及电源问题）之间的高性能和可用性。
这样一来就有了一个相对充足的关于存储系统各个组成部分的错误研究，比如磁盘驱动器，但是目前关于大型云存储服务的报告还相对较少。
我们通过对Google的主存储设施一年的广泛研究的基础上描述了云存储系统的可用性特性，并且提供了统计模型使得我们能更深入的洞察多种设计选择的影响，比如数据存放和复制策略。
利用这些模型，结合我们在工作中发现的真实的失败模式，我们比较不同系统参数下的数据的可用性。
十一、FindinganeedleinHaystack:
Facebook’sphotostorage[大海捞针：
Facebook的照片存储]
本文描述了Haystack，一个针对Facebook相册应用的对象存储系统。
Facebook目前存储了超过2600亿张图像，可以转化为超过20PB（1015字节）的数据。
用户每周上传10亿张照片（大约60TB），Facebook在高峰期需要每秒提供100万张以上的图像。
Haystack提供了一个比以前的通过NFS使用网络附加存储设备的方法开销更低，性能更高的解决方案。
我们最重要的发现是这种传统意义上的设计将会因为元数据的查询导致过多的磁盘操作。
我们小心的删减了每张照片中的元数据，这样Heystack存储机器就能在主存中执行元数据的查询了。
这种选择节省了读取实际数据的磁盘操作，因而提高了整个系统的吞吐量。
十二、AutomaticManagementofDataandComputationinDatacenters[数据中心的自动管理数据和计算]
管理和计算数据是数据中心计算的核心。
人工管理数据可能会导致数据丢失、存储设备的浪费和数据记账的劳动。
缺乏合适的计算管理可能导致失去共享相同的跨多个作业的计算和计算结果增量的机会。
Nectar被设计成解决上述问题的一个系统。
它通过数据中心自动和统一管理数据和计算。
在Nectar中，通过将数据和它的计算相关联，数据和计算被当作可互换的对象。
派生的数据集，也就是计算的结果，被产生它们的程序唯一的识别，和它们程序一起都被全面的缓存服务自动管理。
任何派生数据及都能通过重复执行它们的程序被透明的重新产生，并且任何计算都能使用过去缓存的数据呗透明的避免。
这使得我们大大提高了数据中管理和资源的利用率：
过时的和不常使用的派生数据集都会被自动的垃圾回收，共享的通用的计算只会被计算一次又能被其他程序重复使用。
本文描述了Nectar的设计和实现，并对从几个生产集群和一个240个节点的实际部署中的日志记录进行分析研究撰写了系统的评估报告。
十三、Large-scaleIncrementalProcessingUsingDistributedTransactionsandNotifications[使用分布式事务和通知的大规模的增量处理]
当新的文档来到的时候更新网页的索引文件需要不断的转变大量的现有的文档库。
由于一些小的，独立的改变而改变大型的数据存储是一类数据处理的一个例子。
这种任务的存在是由于现有存储设施能力的差距。
数据库不能满足这类任务的存储和吞吐量的需求：
Google的索引系统存储了数以10PB的数据，数千台机器每天处理数10亿的更新。
MapReduce（一种编程模型，用于大规模数据集（大于1TB）的并行运算）和其他的批处理系统不能独立的处理小量的更新，因为它们依赖于创建大型的批出来来获得效率。
我们构建了Percolator，一个针对大型数据集的增量的处理更新的系统，并把它部署去创建Google网络搜索的索引。
通过使用Percolator这种基于增量处理的索引系统替换基于批处理的索引系统，我们每天处理了相同数量的文档，但是使Google搜索中文档的平均生命减少50%。
十四、Piccolo:
BuildingFast,DistributedProgramswithPartitionedTables[使用分区表构建快速的分布式程序]
Piccolo是一个新型的针对书写数据中心的并行内存应用的以数据为中心的编程模型。
不想已有的数据流模型，Piccolo允许运行在不同的机器上的计算通过键值表接口来共享分布式的易变的状态。
Piccolo允许有效的应用实现。
特别的，应用程序可以自定义本地策略来利用本地的共享状态。
Piccolo运行时使用用户定义的累积函数自动解决写-写冲突。
在一系列的问题域上，我们使用Piccolo实现了应用程序，包括PageRank（页面排序）算法、K-means（K-均值）算法、分布式爬虫算法。
实验使用了100个Amazon EC2[Amazon EC2 （ElasticComputeCloud）是一个让用户可以租用云电脑运行所需应用的系统。
]实例和12个机器集群。
结果证明：
针对很多问题，在提供相同容错保证和方便的编程接口时，Piccolo比以往的数据流模型更快。
十五、ReiningintheOutliersinMap-ReduceClustersusingMantri[使用Mantri控制Map-Reduce集群的离群主机]
针对Map-Reduce的集群操作的实验证明了离群主机极大延长了任务的完成。
处理器的运行时抢占、内存，其他资源以及磁盘的错误、多种带宽、网络路径拥塞、任务负载不均衡都会导致离群。
我们提出了Mantri，一个监视任务和利用原因，资源敏感技术来杀死离群主机的系统。
Mantri的策略包括：
重启离群主机和任务的网络敏感位置以及保护关键任务的输出。
使用实时的进度报告，Mantri检测并在离群主机的生命周期中尽早的采取动作。
尽早的行动释放那些可能被随后的任务使用的资源并能全面加快任务的整体性能。
基于原因、资源、机会的动作使得Mantri提高了提前处理以后会重复执行的任务的性能。
在Bing的产业集群上的部署以及痕迹驱动的模拟显示Mantri将任务完成的时间提高了32%。
十六、TransactionalConsistencyandAutomaticManagementinan
ApplicationDataCache[在应用程序数据缓存的事务连续性和自动管理]
分布式内存应用数据缓存就像内存缓存是解决数据库驱动的网络站点的流行方案。
这些系统很容易添加到部署中，通过减少数据库服务器和应用服务器的负荷大大的提高了性能。
不幸的是，这些缓存并没有与数据库和应用集成的很好。
它们不能保事务在整个系统上的连续性，这就违反了底层数据库独立的性质。
它们让应用负责定位保持缓存中的数据、程序复杂性的根源以及编程错误。
为了解决这些问题，我们介绍一种事务缓存——TxCache，用简单的编程模型制作。
TxCache保证任何数据都能使用事务看到，不管它是来自缓存还是数据库。
TxCache反应了一个略微过期但是连续的数据库快照。
TxCache通过简单的指定函数作为可缓存的方便的将缓存添加到应用中。
它自动的缓存它们的结果，并且当底层的数据库改变时自动刷新缓存数据。
我们的实验发现，添加TxCache将web应用的吞吐量增加了5.2倍。
只是稍微比没有事务的缓存少了一点，证明了连续性不一定要以牺牲性能为代价。
十七、AnAnalysisofLinuxScalabilitytoManyCores[分析Linux对多核的扩展性]
本文分析了7个运行在48核计算机上Linux系统下的系统应用的扩展性（Exim,memcached,Apache,PostgreSQL,gmake,Psearchy,andMapReduce）。
除了gmake，所有的应用都触发了当前Linux内核的扩展性瓶颈。
使用最标准的并行编程技术——本文介绍一种新的技术：
SloppyCounters——这些瓶颈可以从内核中移除，或者通过对应用的略微修改而避免。
修改内核需要改变3002行代码。
从分析中可以得到一个推测性的结论：
到现在，在传统的操作系统组织上，还没有扩展性的原因可以放弃。
十八、FlexSC:
FlexibleSystemCallSchedulingwithException-LessSystemCalls[FlexSC：
使用无异常的系统调用实现灵活的系统调用调度]
在过去的30年里，系统调用已经是事实上的应用程序从操作系统内核请求服务的接口。
当一个特殊的处理器指令是用来产生用户空间来执行内核时，系统调用几乎普遍被实现为同步机制。
本文的第一部分，我们评估传统的同步的系统调用在系统密集任务负载上的性能影响。
我们证明了同步系统调用对性能有显著的负面影响，主要是因为关键处理器结构的管道刷新和污染（例如：
TLB和数据，指令缓存）。
我们为应用程序向操作系统内核请求服务提出了一种新的机制：
无异常系统调用。
它们通过灵活调度操作系统的工作，反过来显著增加用户和内核空间的时间和空间性能来提高处理器的效率，因此减少了处理器结构的污染。
无异常系统调用在多核处理器上尤其有效。
他们主要的适用对象是高度并行的服务程序，例如Web服务器和数据库服务器。
我们提出FlexSC，一个在Linux内核上实现的无异常系统调用和一个用户模式与POSIX线程标准二进制兼容的的线程包（FlexSC-Threads），这使得将传统的同步系统调用转换为无异常的系统调用过程对于应用是透明的。
我们在没有对应用做任何修改情况下，使用FlexSC将Apache的性能提高了116%，MySQL提高了40%，BIND提高了105%。
十九、TrustandProtectionintheIllinoisBrowserOperatingSystem[Illinois浏览器操作系统的信任和保护]
目前的web浏览器都很复杂，有大量的可信计算基础，并为黑客们提供了对现代计算机系统的轻松访问。
本文我们介绍Illinois浏览器操作系统（IBOS），一个为浏览者减少了可信计算新的新的操作系统和浏览器。
在我们的架构中，我们把浏览器层抽象为最低的软件层，通过将直接将浏览器抽象影射到硬件抽象使得我们从可信计算模型中移除了几乎所有的传统的OS组件和服务。
实验证明这种新的架构足够灵活，并允许新的浏览器安全策略，仍能支持传统的应用，而且不要要额外的开销啊就能获得全面的浏览体验。
二十、StarTrackNextGeneration:
AScalableInfrastructureforTrack-BasedApplications[ 下一代StarTrack：
基于痕迹追踪的应用的扩展性结构]
StarTrack是第一个被设计的管理GPS定位坐标轨迹的服务。
这些坐标来源于移动设备，StarTrack方便了基于痕迹追踪应用的构造。
我们起初试图用StarTrack构建一个实用的应用来发现大量可提高效率和扩展性的问题：
比如频繁的CS往返、非必要的数据传输、涉及上千个痕迹的代价相似比较和低容错率。
为了补充这些限制，我们修改了整个系统的架构、API和实现。
API被扩展运行在痕迹的集合而不是单个痕迹上，延迟查询的执行以及允许缓存查询结果。
一种新的数据结构——痕迹树，被设计为能加速常规的相似痕迹的搜索操作。
通过地图匹配算法将将每个痕迹转换为更多紧凑规范的路段序列。
底层的痕迹数据库被分割复制到多个服务器上。
所有被我们用新的API构造的应用确认的这些改变不仅简化了痕迹追踪程序的构造，还带来了客观的性能提高。
比如，对相似痕迹的测量，在查询时间上有了2-3个数量级的改善。
二十一、TaintDroid:
AnInformation-FlowTrackingSystemforRealtimePrivacyMonitoringonSmartphones[ 智能手机实时隐私监控信息流追踪系统]
今天的智能手机操作系统通常还是不能为用户提供对第三方应用使用
升级会员 