2019年8月2日更新：在末尾添加了解释内核补丁和我们发现的其他细节。6月17日，Linux网络堆栈中的三个漏洞被公布。最严重的可能是远程攻击者能够影响系统的可用性。我们相信为客户提供最安全的映像，因此我们很快应用了内核补丁来解决这些问题。自从应用内核补丁以来，我们观察到某些工作负载在amazonwebservices（AWS）平台上经历了意外的、不确定的性能衰退，表现为对S3的长时间或挂起的写入。我们在Microsoft Azure上没有观察到任何性能倒退。尽管在不到0.2%的情况下可以观察到这些倒退，但我们想与您分享我们迄今为止的发现和缓解策略。症状该行为可以在任何Databricks运行时/apachespark版本中显示。受影响的客户将看到运行在Databricks集群上的Spark作业速度减慢，可能会"挂起"15分钟，或者完全由于超时而失败，这是在写入amazons3时发生的。客户可能会在Databricks集群日志中看到与此类似的堆栈跟踪：org.apache.spark网站。火花异常：... 截断。。。原因：com.amazonaws.services网站.s3条。model.amazons3异常:您与服务器的套接字连接未被读取或写入在超时时间内。空闲连接将关闭。客户还可以查看Spark web UI，看到一个或多个任务与同一阶段的大多数其他任务相比花费了异常长的时间。由于安全补丁是在6月24日应用于Databricks平台的，所以性能上的任何变化都将与该日期完全一致。在6月24日（或之后）正常工作并随后经历性能衰退的工作与此问题无关。根本原因TCP SACK DoS漏洞于2019年6月17日被披露。它使远程攻击者能够在接受端口流量的服务器上触发内核死机。我们的基础设施安全团队立即对该问题进行了分析，并决定在我们的常规安全发布序列中将补丁发送到这个CVE。我们以新的Amazon机器映像（Amazon Machine Image，AMI）的形式发布了这个更新，它构成了运行包含Databricks运行时的LXC容器的操作系统的基本映像。在推出补丁后不久，我们在内部基准测试的一小部分和一些客户工作中发现了不确定性异常。例如，写入amazons3的5分钟短数据处理任务需要一个小时才能完成。使用内部基准测试的复制，我们分析了Databricks集群和amazons3之间的网络流量。没有补丁的集群在写入Amazon S3时表现出了预期的行为，在不到90秒的时间内一致地完成了写入：但是，运行在带有安全补丁的集群上的相同代码经历了短时间的数据传输到amazons3，然后是长时间的不活动。以下是一个耗时超过15分钟完成的示例作业：缓解策略我们仍在积极调查这一问题，以确定根本原因。修复这种不确定性的性能回归可能需要另一个操作系统级别的补丁。同时，安全性是我们的默认设置，我们将继续提供最安全的内核。我们会尽快与您分享最新消息。幸运的是，Spark和Databricks的平台从一开始就被设计用来缓解这些类型的长尾分布式系统问题。客户可以在Apache Spark中通过设置火花。猜测在其群集配置中设置为"true"，以缓解此问题。此功能最初设计用于在机器减速的情况下减轻掉队现象。当推测打开时，Spark将启动长时间运行的慢速任务的副本并重试，副本任务很有可能在不影响性能回归的情况下快速完成。对于不希望利用任务推测并可以接受不同的安全威胁模型的客户，我们的支持团队可以与您合作，提供替代的缓解策略。请联系您的客户经理或help@databricks.com如果您受到影响并需要帮助确定解决方法。 2019年8月2日更新我们的AMI在操作系统中使用了未经修改的Ubuntu16.04映像，该映像由Linux 4.4.0内核支持。默认情况下，我们的套接字使用TCP包（S3服务器也是如此），因此我们通过从4.4.0-1084-aws#94 Ubuntu升级到4.4.0-1085-aws#96 Ubuntu来修补TCP SACKs漏洞。当我们继续跟踪这个问题时，我们了解到4.4.0-1087-aws#98 Ubuntu包含了另外三个与TCP sack相关的补丁。其中一个补丁是用来修复sosndbuf较低的套接字的性能。虽然我们使用默认的sosndbuf为16KB，但是我们应用了更新，但是没有看到任何改进。7月19日，一个额外的上游补丁被用来修复另一个低sosndbuf插座的角落情况。因为它还没有被纳入Ubuntu16.04，但是我们用这个补丁构建了一个自定义镜像，它解决了网络性能问题。接下来我们将进行更详细的分析。免费试用Databricks。今天就开始吧