为了有效且高效地调查多租户系统的性能,奈飞(Netflix)一直在尝试使用 eBPF 来对 Linux 内核进行检测,以收集有关进程如何调度并检测“吵闹的邻居”的持续且深入的见解。
使用 eBPF,奈飞(Netflix)的计算和性能工程团队旨在规避一些通常会使“吵闹的邻居”检测变得困难的问题。这些问题包括 perf 等分析工具所带来的开销,这也意味着它们通常仅在问题发生之后才部署,以及工程师所需的专业知识水平。根据奈飞(Netflix)工程师的说法,eBPF 可以实现对计算基础设施进行低性能影响的观测,从而实现对 Linux 调度程序的持续检测。
奈飞(Netflix)工程师确定的关键指标是进程延迟,该指标可指示“吵闹的邻居”可能造成的性能问题:
为了确保依赖于低延迟响应的工作负载的可靠性,我们检测了每个容器的运行队列延迟,该延迟测量了进程在调度到 CPU 之前在调度队列中所花费的时间。
为此,他们使用了三个 eBPF 钩子:sched_wakeup
、 sched_wakeup_new
和 sched_switch
。当进程从“睡眠”状态变为“可运行”状态时,即当它准备好运行并等待一些 CPU 时间时,会调用前两个钩子。当 CPU 被分配给其他进程时, sched_switch
钩子会被触发。因此,进程延迟是通过 CPU 分配给进程的时间戳减去进程首次准备好运行的时间戳来计算的。
最后,在 Go 程序中处理通过插装内核所收集到的事件,以向 Atlas(Netflix 的度量指标后端) 发送度量指标。为了将收集到的数据传递给用户空间的 Go 程序,奈飞(Netflix)工程师决定使用 eBPF 环形缓冲区,它提供了一种高效、高性能且用户友好的机制,不需要额外的内存复制或系统调用。
除了计时信息外,eBPF 还可以收集有关进程的其他信息,包括将进程与容器关联起来的进程的 cgroup
ID,这是正确诠释抢占的关键。事实上,检测“吵闹的邻居”不仅仅是测量延迟的问题,因为它还需要跟踪进程被抢占的频率以及是哪个进程导致的抢占,无论它们是否运行在同一个容器中。
例如,如果一个容器达到或超过其 cgroup
CPU 的限制,调度程序将对其进行限流,从而会导致由于队列延迟而引起的运行队列延迟明显增加。如果我们只考虑这个指标,我们可能会错误地将性能下降归因于“吵闹的邻居”,而实际上这是由于容器达到了它的 CPU 配额上限导致的。
为了确保他们的方法不会影响被监测系统的性能,奈飞(Netflix)的工程师还创建了一个用于测量 eBPF 代码开销的工具 bpftop。使用该工具,他们可以确定几类优化,以进一步减少它们最初的开销,并使每个 sched_*
钩子的时延保持在 600 纳秒的阈值之下。从而使其能合理地不断运行钩子,而不必担心它们会对系统性能造成影响。
如果你对这种系统性能监测方法感兴趣,或者想更好地了解 eBPF 的内部工作原理,原始文章所提供的细节要比这里所介绍的详细得多,其中还包含了有用的示例代码。
作者介绍
Sergio De Simone 作为一名软件工程师已经有超过 25 年的工作经验了,曾在一系列不同的项目和公司工作过,包括西门子、惠普和小型初创公司等不同的工作环境。在过去的十多年里,他一直专注于移动平台和相关技术的开发。他目前就职于 BigML, Inc.,负责 iOS 和 macOS 的开发。
查看原文链接:
https://www.infoq.com/news/2024/09/ebpf-noisy-neighbors/
评论