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

为了我们的客户和他们的观众的利益而改进我们的技术性能是Verizon 媒体持续的行动方针, 现在Edgio. 例如, 在过去的两年里, 我们的性能和内核工程师已经消除了几乎所有的丢包(超过98%), 将边缘服务器的性能运行状况检查提高了50%, 并将服务器容量提高了40%.

我们还将上述功能与网络自动化和有机网络扩展(目前超过250tbps)相结合，以改善用户体验. 当我们为数百万台游戏机提供软件更新时，仔细调整我们的性能在我们支持快速变化和有时不可预测的网络激增的能力中发挥了重要作用, 主要体育赛事的实时视频流, 当多cdn负载均衡器将负载转移到我们的网络时.

在规模上保持质量涉及到 优化性能 横跨Edgio 媒体 Platform技术栈的每个部分:从底层开始, 在中央处理器和网卡, 到操作系统和应用程序. 最终，我们的目标始终是相同的:出色的表现. 要到达那里, 我们执行数据驱动的分析, 依靠可衡量的绩效变化来验证我们的决策.

CPU缓存优化

我们跑了20,全球5000台服务器, 主要是Broadwell和Haswell芯片组, 通常有32到40个内核. 仅在过去三年，我们就增加了12000台服务器. 然而，大多数服务器并没有针对我们的工作负载进行优化. 简单地添加更多服务器并不能提高操作效率，还会带来额外的挑战. 有效的扩展需要对现有组件进行仔细的优化. 能够优化一台服务器，使其能够处理比默认配置多两到三倍(或更多)的请求，这将对网络的整体性能产生巨大影响.

从早期窥探到居家窥探的转变

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

默认情况下，我们的硬件供应商使用一种称为Early Snoop的协议. 它具有较低的延迟来解决缓存一致性, 由于所有核心可以同时发出缓存一致性请求并发出广播. 我们发现，在峰值负载场景中，我们的系统会同时产生大量的磁盘和NIC活动. 这些活动导致高窥探广播，导致通信瓶颈. 这会导致IO设备变慢，并最终导致处理完全停止.

通过切换到Home Snoop模式, 一种整合窥探请求的方法, 我们看到广播流量显著减少. The processor’s Quick Path Interconnect (QPI) is no longer starved during periods of simultaneous heavy disk and network IO operations; furthermore, 我们看到早期Snoop的数据包丢失数量显著减少.

更改snoop协议仅取决于更改BIOS设置. 但是，在不中断客户的情况下重新启动20,000台服务器需要自动化. 我们可以在生产环境中进行这种大规模的部署变更，这部分要归功于我们基于stackstorm的IT自动化平台, 小龙虾.

意外的故障转移事件

在测试切换到Home Snoop时, 发生了故障转移:我们最大的媒体客户之一, 它有一个 multi-CDN部署, 遇到了另一个供应商的问题，并将他们的很大一部分流量转移到我们的CDN. 这为测试大规模的Home Snoop改进提供了机会, 哪些是极具影响力的.

上图显示了更改的效果. 仍然使用Early Snoop的小组的下降幅度增加了13.75x(每台服务器每天丢55K数据包), 而换成Home Snoop的那组只增加了4个.23x(每台机器每天丢包27K). Home Snoop在故障转移事件中立即证明了它的价值.

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

另一组重要的性能调优涉及网络接口和驱动程序. 在这里，我们专注于减少通常发生在突发流量中的数据包丢失. 大型活动期间, 入站流量太大，NIC无法跟上, 而且我们看到的数据包掉落比预期的要早. 当我们深入研究原因时, 我们发现网卡本身的几个参数需要调整, 包括队列的数量, 队列大小, 中断调度. 为我们的特定工作负载和硬件配置优化这些规范, 我们主要通过延长入站队列来调优接收端缩放(RSS), 减少它们的总数, 并平衡NUMA节点之间的中断.

上面的图表显示了我们在北美运行的一个测试，其中每个PoP被划分为一个控件(i.e.(未调谐)组和一个测试(i.e.调谐)组. 这里，我们给出了一周内每天的滴数总和. 以下是调优, 我们的测试组看到大约95%的数据包比对照组少, 允许处理更多的请求. 这也意味着在激增期间手动管理网络运行状况所需的操作更少, 让我们的工程师可以专注于其他领域.

CPU调度调优

而NIC和驱动级调优集中在提高我们可以提供的总容量, CPU调度优化的重点是增强我们交付内容的一致性.

如果没有这些调优，入站和出站消息就必须争夺资源. 当我们开始调查根本原因时, 我们发现，对资源的争用源于内核如何调度这些消息的处理. 这意味着直到cpu饱和之后，负载才会在高峰流量期间迁移出去. 为了解决这个问题, 我们将web服务器进程的CPU亲和性设置为排除专门用于处理传入网络流量的CPU.

上图显示了3月21日至22日在CDN上全局启用CPU调度调优的影响. 我们根据a的第95个百分位和中位数来评估影响 性能运行状况检查指标，显示服务器相对响应时间的复合指标. 正如预期的, low-traffic valleys were not significantly reduced; however, 峰值显示传入和传出流量之间的争用显著减少. 这转化为异常值和中位数的重大改进, 特别是在高峰负荷期间. 我们现在可以更好地处理流量激增，并解决与高异常行为相关的问题, 例如视频流中的重新缓冲或服务器对所有用户的总体响应能力.

内核性能更新

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

在上面的图表中, 从11月底到1月初，您可以看到升级过程的影响，性能运行状况检查的第99个百分位数有所下降. 底层内核的改进使得我们所有的web服务器请求处理器的负载分布更加均匀. 这导致了这些异常值的大幅下降, 使所有客户的要求更可靠.

性能调优有很大的影响

在过去的两年里, 性能和内核工程部署的影响深远的系统调优几乎消除了所有丢包(超过98%被删除)，并将边缘服务器上的性能健康检查减少了一半. 我们的服务器容量增加了10-40%(确切的数量根据客户配置文件和事件而变化), 使我们能够更快地提供更多的流量. 异常行为有了显著改善, 创造更加一致的体验, 我们看到中位数有了很大的改善, 特别是在高峰负荷期间. 总之， 性能调优 整个技术栈使我们能够更好地处理任何意外的流量峰值(无论是来自备受期待的游戏机更新还是流行的流媒体视频直播事件)，并为所有用户提供更一致的性能.