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

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

About The Author

Outline

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

我们还将上述内容与网络自动化和有机网络扩展(目前超过250 Tbps)相结合,以改善用户体验。 当我们为数百万台游戏控制台提供软件更新,为主要体育赛事提供直播视频流,以及当多CDN负载平衡器将负载移动到我们的网络时,仔细调整我们的性能在我们支持快速变化且有时不可预测的网络激增的能力方面发挥了重要作用。

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

CPU缓存优化

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

从早期snoop切换到家庭snoop

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

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

通过切换到Home Snoop模式(一种合并snoop请求的方法),我们已看到广播流量显著减少。 处理器的Quick Path Interconnect (QPI)在同时进行大量磁盘和网络IO操作期间不再缺电;此外,我们在早期Snoop中看到的数据包丢弃数量显著减少。

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

意外的故障转移事件

在测试切换到Home Snoop时,发生了故障转移:我们最大的媒体客户之一( 部署了多CDN)遇到了与其他供应商的问题,并将其流量的很大一部分转移到了我们的CDN。 这提供了一个测试大规模家庭监控改进的机会,这些改进具有极大的影响力。

上图显示了更改的影响。 仍然使用早期Snoop的组的数据丢失次数增加了13.75倍(每台服务器每天丢失55K个数据包),而切换到Home Snoop的组只增加了4.23倍(每台计算机每天丢失27K个数据包)。 Home Snoop在故障转移事件中立即证明了其价值。

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

另一组重要的性能调整涉及网络接口和驱动程序。 在这里,我们重点关注如何减少通常与突发流量一起发生的数据包丢弃。 在大型事件期间,入站流量非常大,以至于网卡无法跟上,而且我们看到数据包的丢弃速度比预期的要快。 当我们深入了解原因时,我们发现网卡本身有几个参数需要调整,包括队列数量,队列大小和中断调度。 为了针对我们的特定工作负载和硬件配置优化这些规范,我们集中精力调整接收端扩展(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%(具体数量因客户资料和事件而异),使我们能够更快地提供更多流量。 离群值行为显著改善,使体验更加一致,并且我们看到中位值有良好改善,尤其是在峰值负载期间。 总之, 针对整个技术堆栈进行的性能优化 使我们能够更好地处理任何意外流量高峰(无论是来自备受期待的游戏控制台更新还是流行的流视频直播活动),并为我们的所有用户提供更一致的性能。