用蜜蜂(eBPF)来追踪海豚(MySQL)，性能追的上吗

数据运维 2024-06-07 大树 手机阅读

DBdoctor 基于 eBPF 实现了数据库可观测，能够在不改代码、不改启动参数、不重启进程的前提下对数据库内核进行追踪，拿到更细粒度的内核数据进行数据分析，做到了性能观测的数学模型化。在数据库领域这是一种全新的技术手段，但偶尔也有小伙伴会咨询一些不解：

eBPF观测MySQL做出来是不是一个玩具？能否用于生产？

每一条SQL执行过程都探测，对数据库的性能消耗到底有多大？

让一只蜜蜂(eBPF)去追海豚（MySQL），能追得上吗？

本文将用数据说话，带大家一起用压测对比的方法揭开以上谜团！

因测试比较严谨，全文比较长，忙碌的小伙伴可直接查看最下方的总结。

Agent采集处理流程中，哪些环节会存在开销？

对于Agent来说占用资源是一定的，那如何才能做到最小化资源占用？下面将详细展开DBdoctor是怎样进行资源消耗控制的。

用蜜蜂(eBPF)来追踪海豚(MySQL)，性能追的上吗-1

Agent利用eBPF实现对MySQL的内核探测，从原理机制上看eBPF的消耗主要在CPU上，CPU的消耗包含以下两个方面：

1）内核态探测开销

当我们对MySQL内核的某个函数增加探测，相当于在函数的进入和返回都会执行我们自定义的eBPF程序，执行完后再进行MySQL的下一步执行。那这里增加的开销就是函数被调用的时候执行eBPF程序代码的开销（实际占用的是MySQL进程的CPU资源）。

从上图我们能看到，控制单次调用消耗和调用频率尤为重要。在实际生产中这两个指标的性能开销该如何控制呢？

理解Agent处理流程以后，我们希望设计一组测试，尤其是针对性能要求很高的OLTP数据库。与业界其他可观测厂商测试方法不同，比如基于eBPF探测APP应用，一般都是注入多少负载压力的情况下进行测试评估性能损耗，我们要求是在极端负载压力情况下（数据库性能诊断的初衷就是要在数据库极端情况下进行关键数据采集，才能分析出性能问题根因），希望该测试用例能评估以下几点：

  • Agent 的运行对业务性能有什么样的影响？

    • 业务的 QPS/TPS 降低了多少？

    • 业务的 RT（Response Time）升高了多少？

    • 业务的 CPU/MEM 消耗升高了多少？

  • Agent 自身的处理性能如何？

    • 特定压力下 Agent 的 CPU/MEM 消耗如何？

2）用户态数据处理开销

探针采集到详细MySQL内核指标数据后，agent需要对数据进行组装处理，最后再通过网络投递出去进行存储。

从图上我们能看到，16c16g规格的主机，我们给agent容器资源限制在1c1g，这样可以保证Agent不会抢占主机资源（稳定性兜底），这块资源占用很小，可以忽略不计。

如何进行测试，才能评估出eBPF开销？

首先，为了评估 Agent对业务性能的影响，我们希望设计典型的业务场景来进行评估，并希望能覆盖到 Agent 处理流程中的所有重要环节。我们一共设计了两个场景，如下图所示：

用蜜蜂(eBPF)来追踪海豚(MySQL)，性能追的上吗-2

1）通过典型业务场景评估 Agent 对业务性能的影响

  • 场景 A - 基准压测只读、只写、读写混合场景
    使用 sysbench 作为压力工具，分别在读写、只读、只写模式下不同并发时的性能（TPS、QPS）。

    • 分别对4c8g(bp:4G)/8c16g(bp: 8G) 的MySQL 使用1c1g/2c1g的Agent进行压测，没有部署Agent压测的消耗数据作为对照。

    • 分别在并发用户数为1/2/4/8/16/32/64 的情况下进行测试。

    • 每个测试运行30分钟，收集TPS和QPS性能数据、Agent 的实际物理资源消耗数据、对MySQL CPU资源的消耗数据。

  • 场景 B - 典型订单交易 OLTP 场景
    交易场景在数据库中是比较典型的OLTP类型，而且经常会有性能相关问题，特别是大促等场景下尤为突出。TPC-C 模型下的压测，评估Agent对业务处理能力的影响程度。

  • 场景 C - 数据库单个 SQL 请求消耗场景
    MySQL的SQL执行过程探测，都会执行对应的探测点 eBPF 程序，该程序的开销即业务性能的影响开销。该测试通过给程序增加打印（仅内部验证评估使用）。所有上述三大场景，我们均会分别测试停用 Agent（基线）、运行Agent 两种情况，通过对比得出 Agent 对业务性能的影响。另外，我们也会注入不同 TPS 的压力，直至达到业务极限处理能力，以评估不同压力下的影响是否存在差异。另一方面，对于Agent进程自身处理性能的评估，我们会记录场景 A、B、C 中Agent 进程的 CPU/MEM开销。除此之外，我们也希望设计一些更极端的场景，用来评估Agent在资源受限情况下的资源消耗和极限处理能力。Agent的处理主要是读取数据并网络投递的开销，没有做其他逻辑的处理，所有开销主要在CPU上，那么CPU的开销和QPS有关，我们需要验证QPS对 Agent 资源消耗的影响。

2）评估 Agent 自身的处理性能

  • 场景 A - 只采集主机性能数据
    我们只采集主机和实例资源相关的性能数据，不开启性能洞察和锁分析，同时纳管一个机器上多个数据库实例，并评估 Agent 需要占用多少 CPU/MEM 资源。

  • 场景 B - 开启全功能采集并压测实例
    基于压测工具不断增加 QPS 的量，评估 Agent 的 CPU/MEM 资源占用与QPS的关系，我们将会对所有上述 2 个场景的测试方法和结果进行详细的阐述。测试过程中 DBdoctor Agent全部使用默认配置，没有进行任何调优。帮助用户评估业务量需要多少 Agent资源配置。

给数据库施压，Agent对业务的影响到底有多大？

通过分析Agent的处理流程，我们设计了3大场景进行全方位评测。

测试环境信息：

数据库服务器：ECS 独享cpu CPU：Intel(R) Xeon(R) Platinum 8269CY CPU @ 2.50GHz ECS规格：16c16g 机器内存：32GB DDR4 mysql版本：5.7.37 操作系统：CentOS Linux 8 内核版本：4.18.0-348.7.1.el8_5.x86_64