为了有效且高效地调查多租户系统的性能，奈飞（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 的开发。
声明：本文由 InfoQ 翻译，未经许可禁止转载。