诊断 MariaDB 随机冻结问题

# 诊断 Frappe Cloud 上 MariaDB 的随机冻结问题 Source: https://frappe.io/blog/frappe-cloud/diagnosing-random-mariadb-freezes-on-frappe-cloud 在 Frappe，我们在 Frappe Cloud 上托管了数千个站点。当一台数据库服务器宕机时，受影响的不仅是一位客户，而是该服务器上的所有站点。因此，当我们在每周指标回顾中反复发现数据库冻结时，我们意识到出了问题。 在过去几个季度，大多数事故类别都显著减少。然而，数据库事故仍然不断出现，呈现出两种反复出现的模式：磁盘 I/O 突然飙升，随后数据库完全冻结，导致服务器无响应。每周，我们在共享和专用服务器上都能观察到 5 到 6 起此类事故。 DB 突发 I/O 飙升 如果这是由简单的资源耗尽引起的，解决方案会很直接：升级数据库服务器。但这些故障并非如此。飙升后冻结的模式表明，有某种因素触发了活动的突然爆发，而不是逐渐累积。 首先，我们需要找出触发原因。 ## 可观测性难题 事实证明，调查起来比预期更难。当服务器承受巨大的 I/O 压力时，磁盘队列会被填满，甚至常规的 OS 操作也开始等待磁盘访问，包括 SSH daemon 和我们用于监控的指标 exporter。就在最需要可见性的时刻，系统实际上陷入了“黑暗”。 我们的监控链路依赖固定间隔采集指标，但在高负载下，exporter 常常无法及时响应。结果，关键数据根本没能被捕获。 为了排查此问题，我们需要看清系统为何处于压力之下。其中两个问题最为关键： 1. 事故发生时正在运行哪些查询？ 2. 数据库正在读取或写入哪些文件或表？ ## 使用 eBPF 追踪数据库 I/O 第一个问题很容易通过 MariaDB 的进程列表来回答。 第二个问题则需要追踪磁盘活动。为此，我们使用了 eBPF，这是 Linux 的一项特性，允许你将小程序直接附加到内核函数上，观察 OS 内部发生了什么。你可以把它想象成在内核层面放置了一名无声的观察者，而无需修改内核本身。 我们编写了一个小型 eBPF 程序来追踪 MariaDB 的 I/O 活动。该工具使用了两个 eBPF 钩子： - `kprobe/vfs_read` 和 `kprobe/vfs_write`：当进程执行读或写操作时被触发。 - `kretprobe/vfs_read` 和 `kretprobe/vfs_write`：在内核处理完请求并将数据返回给进程后被触发。 eBPF 事件处理器 通过为每个文件描述符配对进入和退出事件，我们可以检测到卡住的 I/O：如果发起了 `vfs_read` 但始终未返回，说明磁盘已经难以跟上。每次发生这种情况，I/O 监控器都会记录相关发现，以供进一步调查。 保持钩子处于活动状态会导致 I/O 变慢，因此我们引入了一个资源监控器。它会监视 CPU iowait 或磁盘活动的飙升，并按需附加 eBPF 探针。 作为参考，你可以查看 [eBPF 程序](https://github.com/frappe/press/blob/develop/libs/mariadb_io_monitor/bpf/io_trace.bpf.c) 和 [事件处理器](https://github.com/frappe