Home 技术文章 大规模服务器优化:消除数据包丢失并提高容量
Applications

大规模服务器优化:消除数据包丢失并提高容量

About The Author

Outline

为客户及其受众的利益提高我们的技术性能是Verizon Media (现为Edgio)的一项持续行动。 例如,在过去两年中,我们的性能和内核工程师几乎消除了所有数据包丢弃(删除的数据包超过98%),将边缘服务器的性能运行状况检查提高了50%,并将服务器容量提高了40%。

我们还将上述功能与网络自动化和有机网络扩展(目前超过250 Tbps)相结合,以改善用户体验。 在我们为数百万个游戏机提供软件更新,为大型体育赛事提供直播视频流,以及多CDN负载平衡器将负载转移到我们的网络时,仔细调整我们的性能对于我们支持快速变化,有时是不可预测的网络浪涌的能力起到了重要作用。

大规模维护质量涉及优化Edgio Media Platform技术堆栈的每个部分的性能:从低层到CPU和网卡,再到操作系统和应用程序。 最终,我们的目标始终是相同的:卓越的性能。 为了实现这一目标,我们执行数据驱动型分析,依靠可衡量的性能变化来验证我们的决策。

CPU高速缓存优化

我们在全球运行20,000台服务器,主要是Broadwell和Haswell芯片组,通常具有32至40个内核。 仅在过去三年中,我们就增加了12,000台服务器。 但是,大多数服务器没有针对我们的工作负载进行优化。 仅仅添加更多服务器并不能提高运营效率,还会带来更多挑战。 有效的扩展需要仔细优化现有组件。 能够优化一台服务器,使其能够处理两到三倍(或更多)的请求,而不是默认配置,可以对网络的整体性能产生巨大影响。

从早期snoop切换到家庭snoop

现代CPU采用snoop协议来保证本地CPU缓存与内存一致。 这使缓存可以侦听对任何CPU上的变量的修改,并相应地更新这些变量的版本。 毫不奇怪,使用的特定技术会显著影响内存性能。

默认情况下,我们的硬件供应商使用名为Early Snoop的协议。 它具有更低的延迟来解析缓存一致性,因为所有内核都可以同时发出缓存一致性请求并发出广播。 我们发现,在高峰负载情况下,我们的系统会同时产生大量磁盘和网卡活动。 这些活动导致高监听广播,导致通信瓶颈。 这会导致IO设备运行缓慢,并最终导致处理完全停止。

通过切换到Home Snoop模式(一种合并snoop请求的方法),我们看到广播流量显著减少。 处理器的快速通道互连(QPI)在同时执行大量磁盘和网络IO操作时不再会耗尽;此外,我们在早期Snoop中看到的数据包丢失数量显著减少。

更改snoop协议仅取决于更改BIOS设置。 但是,在不中断客户的情况下重启20,000台服务器需要自动化。 我们可以在生产中实现这种大规模部署更改,部分原因是我们基于StackStorm的IT自动化平台Crayfish。

意外故障转移事件

在测试切换到Home Snoop的过程中,发生了故障转移:我们其中一家拥有多CDN部署的最大媒体客户遇到了另一家供应商的问题,并将其大部分流量转移到我们的CDN。 这为测试大规模Home Snoop改进提供了一个机会,这些改进具有极大的影响。

上图显示了更改的效果。 仍在使用Early Snoop的团队的数据包丢弃次数增加了13.75倍(每个服务器每天有55000个数据包丢弃次数),而切换到Home Snoop的团队的数据包丢弃次数仅增加了4.23倍(每个计算机每天有27000个数据包丢弃次数)。 Home Snoop在故障转移事件中立即证明了其价值。

网络接口优化和驱动程序调整

另一组重要的性能调整涉及网络接口和驱动程序。 在这里,我们重点关注减少通常与突发流量一起发生的数据包丢弃。 在大型事件期间,入站流量太大,NIC无法跟上,而且我们看到数据包丢失的速度比预期的要快。 当我们深入探究原因时,我们发现网卡本身的几个参数需要调整,包括队列数量,队列大小和中断调度。 为了针对特定的工作负载和硬件配置优化这些规范,我们集中精力调整接收端扩展(RSS),方法是延长入站队列的长度,减少其总数,并平衡NUMA节点之间的中断。

上图显示了我们在北美进行的一项测试,其中每个流行音乐被分为一个控制(即未调谐)组和一个测试(即调谐)组。 在这里,我们提供一周内每天累计的滴落次数。 经过调整后,我们的测试组发现的数据包丢失比对照组少95%左右,因此需要处理的请求显著增加。 这也意味着在浪涌期间手动管理网络运行状况所需的操作更少,让我们的工程师可以专注于其他领域。

CPU调度调整

NIC和驱动程序级别调整集中于提高我们可以交付的总容量,而CPU调度调整则集中于提高交付内容的一致性。

如果没有这些调整,入站和出站消息就必须竞争资源。 当我们开始调查根本原因时,我们发现对资源的争用是由内核如何调度处理这些消息引起的。 这意味着负载在峰值流量期间不会迁移到有问题的CPU饱和之后。 为了解决这一问题,我们将Web服务器进程的CPU关联性设置为排除专用于处理传入网络流量的CPU。

上图显示了3月21日至22日在CDN中全局启用CPU调度调整的影响。 我们根据性能运行状况检查指标的第95百分位数和中位数来评估影响,该指标是一种显示服务器相对响应时间的复合指标。 正如预期的那样,低流量山谷并未显著减少;然而,峰值表明进出流量之间的争用显著减少。 这意味着异常值和中位数都有了重大改善,特别是在峰值负载期间。 现在,我们可以更好地处理流量激增,并消除与高异常值行为相关的问题,例如视频流中的重新缓冲或服务器对所有用户的整体响应速度。

内核性能更新

优化我们技术堆栈的上层与调整下层元素同等重要。 在最近升级操作系统的过程中,我们还升级了Linux内核,以充分利用Linux内核社区的上游工程工作。 新内核比以前部署的版本有大约四年的开发,包括内存管理系统的改进,这减少了阻塞页面分配,改善了负载分布和性能,当使用epoll API和套接字分层时。

在上图中,您可以看到11月底至1月初升级过程的影响,即性能状况检查在第99百分位数下降。 基础内核的改进使我们所有的Web服务器请求处理器的负载分布更加均匀。 这导致这些异常值大幅下降,从而使对我们所有客户的请求更加可靠。

性能调整具有显著的影响

在过去两年中,性能和内核工程部署的意义深远的系统调整几乎消除了所有数据包丢失(删除的数据包超过98%),并使我们在边缘服务器上的性能运行状况检查减少了一半。 我们的服务器容量增加了10–40%(具体数量因客户资料和事件而异),使我们能够更快地提供更多流量。 离群值行为已显著改善,使体验更加一致,我们看到中位数有了良好改善,尤其是在峰值负载期间。 总之,对整个技术堆栈的性能调整使我们能够更好地处理任何意外流量峰值(无论是来自高度预期的游戏控制台更新还是流行的流视频直播活动),并为所有用户提供更一致的性能。