Linux PSI 触发器如何在压力超过阈值时通知进程

服务延迟偶尔尖刺，但每十秒读取一次 /proc/pressure/memory 时，avg10 又不算高，这类问题很容易被平均值掩盖。Linux PSI 触发器提供了更直接的办法：把“某个时间窗口内允许的累计停顿上限”写入对应压力文件，再让进程用 poll() 等待 POLLPRI 事件。

例如 some 300000 2000000 表示：在任意 2 秒窗口内，只要部分任务因该资源累计停顿达到 300 毫秒，就唤醒监听进程。数值单位都是微秒，trigger 与用于等待通知的文件描述符绑定，关闭该描述符后监视自动注销。

Linux 内核文档：https://docs.kernel.org/accounting/psi.html

现场：平均值正常，短时停顿却拖慢了请求

一次内存回收压力导致请求尾延迟突然升高，应用层监控只看到几秒钟的抖动。事后查看 PSI 的 avg60 和 avg300，数字已经被更长窗口摊薄；如果告警只盯这些趋势值，短时但剧烈的资源争用可能不会触发动作。

PSI 的 total 能累计绝对停顿时间，但定时读取仍存在采样间隔。trigger 的价值在于把判定放进内核：当指定窗口内的 PSI 信号增长超过阈值，内核唤醒已经在等待的用户态进程，进程再决定记录快照、暂停低优先级任务、迁移负载或启动降载。

系统级 CPU 的 full 没有定义；内核为了兼容会报告零。监控 CPU 时通常选择 some，而内存与 I/O 可以根据业务容忍度选择 some 或 full。

PSI 触发器到底绑定了哪些对象

触发器不是写完字符串就独立存在的全局配置。它绑定到本次 open() 得到的文件描述符。程序把阈值写入描述符后，继续保留它，并用 select()、poll() 或 epoll() 等待事件；关闭描述符，trigger 就随之注销。

因此两个不同阈值不能复用同一个文件描述符。即使都监控 /proc/pressure/memory，也要分别调用两次 open()。在已经绑定 trigger 的描述符上再次 write()，内核会返回 EBUSY。

把阈值写成“累计停顿量 + 观察窗口”

trigger 不是 CPU 利用率或内存使用率百分比，而是指定窗口内的累计停顿时间。格式只有三个字段：

some 300000 2000000

这表示监控 some 压力，在 2,000,000 微秒的窗口内，累计停顿达到 300,000 微秒时触发。换成比例理解约为 15%，但内核接口接收的是两个微秒数，不是百分比。

选择参数时先从业务 SLO 反推。例如接口允许 2 秒内最多因内存压力损失 300 毫秒，就用上面的值。不要直接照搬别人的阈值；同一个停顿比例对在线请求、批处理和后台压缩任务的影响不同。

用 poll 等待 POLLPRI 通知

下面是一个独立的内存 PSI 监听器。它使用 2 秒窗口，便于普通用户在满足系统权限的情况下注册；当 some 累计停顿超过 300 毫秒时，poll() 返回 POLLPRI。

#include 
#include 
#include 
#include 
#include 
#include 

int main(void) {
    const char *path = "/proc/pressure/memory";
    const char trigger[] = "some 300000 2000000";

    // 读写模式用于注册 trigger，NONBLOCK 避免文件操作意外阻塞
    int fd = open(path, O_RDWR | O_NONBLOCK);
    if (fd 

编译和启动可以保持很简单：

# 编译为独立监听器；-Wall/-Wextra 用于暴露常见 C 错误
cc -O2 -Wall -Wextra psi-watch.c -o psi-watch

# 前台运行，便于由 systemd 或其他监督器接管生命周期
./psi-watch

如果 /proc/pressure 不存在，先确认内核是否启用 PSI，而不是循环重试打开文件。生产程序还应把事件交给有去抖、冷却时间和幂等性的策略模块，避免一次持续压力触发多次昂贵动作。

触发后应该做什么，而不只是打印一行日志

内核只负责告诉你阈值被越过，不知道业务该牺牲什么。在线服务可以减少接入并发、暂停低优先级队列、缩短缓存回填批次；批处理平台可以冻结可重启任务；节点代理可以记录进程、内存回收和 I/O 快照，再把状态上报给调度器。

建议把响应分成两层：

• 快速层：只记录事件时间、资源类型、阈值和当前动作，立即返回 poll()。
• 策略层：结合连续触发次数、业务延迟和冷却时间，决定限流、暂停、迁移或恢复。

这样可以避免监控进程自己在压力最重时执行大量诊断，反过来加剧资源争用。

从系统级扩展到 cgroup v2

当内核启用 CONFIG_CGROUPS=y 并挂载 cgroup v2 后，每个 cgroup 目录都有 cpu.pressure、memory.pressure 和 io.pressure。这些文件的格式与系统级 PSI 相同，trigger 的注册和 poll() 用法也一致。

// 只监控目标服务 cgroup 的内存压力，避免整机噪声掩盖业务边界
const char *path = "/sys/fs/cgroup/my-service/memory.pressure";

注意 cgroup 被删除时，等待中的描述符可能报告 POLLERR。监控代理应结束旧监听，再由上层发现新的 cgroup 路径并重新注册，而不是继续在失效描述符上等待。

常见失败与排查顺序

1. 打开失败：检查 PSI 接口是否存在、路径是否属于预期 cgroup，以及进程权限。
2. 写入返回 EINVAL：核对 some/full 拼写、微秒单位、窗口范围和无特权用户的 2 秒倍数要求。
3. 写入返回 EBUSY：该文件描述符已经绑定一个 trigger，为新 trigger 重新 open()。
4. 一直没有事件：确认资源类型选对、阈值没有高于真实停顿、程序确实在同一描述符上 poll。
5. 事件后动作过多：记住内核已按窗口限频，但策略层仍需冷却时间和幂等控制。
6. 收到 POLLERR：把事件源视为失效，关闭描述符并重建监控对象。

相关问题

PSI trigger 能直接设置百分比阈值吗？

不能。接口接收累计停顿微秒数和窗口微秒数。可以先按业务目标换算比例，再把结果写成两个绝对时间值。

同一个压力文件能注册多个 trigger 吗？

可以，但每个 trigger 必须使用单独的文件描述符。一个描述符上已有 trigger 时再次写入会返回 EBUSY。

为什么普通用户写 1 秒窗口会失败？

内核文档规定，无特权用户的窗口长度必须是 2 秒的整数倍，以限制监控开销。需要普通用户运行时，可从 2 秒窗口开始设计阈值。

PSI 触发器可以替代 avg10 告警吗？

不完全替代。trigger 适合捕获指定窗口内的尖刺并触发动作，avg10/60/300 更适合观察持续趋势和容量变化，两者结合更完整。

监听 CPU 压力时应该用 some 还是 full？

系统级 CPU 的 full 未定义并保持为零，通常使用 some。cgroup 场景仍应先根据内核和工作负载语义核对指标，再设置阈值。

这次排障真正补上的不是一条告警，而是从“定时看平均值”到“让内核按业务窗口通知”的机制。把 trigger、独立文件描述符和 POLLPRI 监听固定下来，再把降载策略放到有冷却和幂等控制的模块里，短时资源压力才不会继续悄悄穿过监控。