如何使用SIGSTOP与SIGCONT将进程CPU使用率严格限制在指定值内

你当前实现出现小幅超阈值的核心原因是控制环路的滞后性与临界震荡问题，具体有三点：

• 采样控制存在固有延迟：你等采样周期结束、计算出CPU使用率超过阈值后才发SIGSTOP，此时进程已经在阈值以上运行了一整个采样间隔，加上信号从发送到内核真正暂停进程的调度延迟，多消耗的CPU时间会直接把统计值抬过设定阈值
• 判断逻辑没有预留控制余量：当前逻辑是“到阈值就停、低于阈值就放”，属于临界触发逻辑，没有给延迟留缓冲，必然会在阈值附近出现冲高超出的情况
• 统计口径存在偏差：当前计算CPU使用率时直接乘以整机CPU核数，和top命令的统计逻辑不一致——top默认单进程单线程跑满单核即为100%，和整机核数无关，直接乘整机核数会在多核场景下出现计算值偏高/偏低的偏差。

按照以下四点修改即可稳定把进程CPU使用率压在设定阈值以下：

• 增加控制缓冲余量：不要卡着设定阈值触发停止，比如设定20%限制时，以阈值的95%（即19%）作为SIGSTOP触发线，等CPU使用率降到比触发线低2-3个百分点时再发SIGCONT，既覆盖调度延迟，也避免信号在阈值附近频繁切换导致的震荡
• 缩短采样间隔、减小控制滞后：把采样间隔调整到10~20ms，计算平均使用率时仅取最近100ms的统计窗口，不要用30个采样点的长窗口，长窗口会大幅拉长控制响应时间，超调会更明显
• 对齐统计口径：如果是限制单线程进程，不需要乘以整机核数；如果是多线程进程，乘以进程分配到的CPU核心数即可，不要直接取整机总核数计算
• 增加超用时间补偿机制：每次触发停止时，计算当前采样周期内进程已经超用的CPU时间，停止期间先抵扣完超用的时间再判断是否恢复运行，避免超用的CPU时间累积到统计值里造成持续超阈值。

将原代码中信号判断的部分替换为如下实现即可：

// 控制参数定义，可根据实际场景微调
#define TRIGGER_RATIO 0.95    // 停止触发线为设定阈值的95%，留5%延迟余量
#define RESUME_GAP 3.0        // 恢复运行的阈值比停止触发线低3%，避免震荡
long long overuse_time = 0;   // 累计超用的CPU时间，用于补偿控制

//********** calculate, send signals ***************
double cpu_usage = (proc_time_since * 100.0) / total_time_since;
// 多线程场景下替换为进程分配到的CPU核心数，单线程场景注释掉下一行即可
// cpu_usage *= conf->allowed_cpus;

double stop_line = conf->percent * TRIGGER_RATIO;
double resume_line = stop_line - RESUME_GAP;

if (!is_stop) {
    if (cpu_usage >= stop_line) {
        // 累计当前周期超用的CPU时间
        long long expect_runtime = total_time_since * stop_line / 100.0;
        overuse_time += (proc_time_since - expect_runtime);
        kill(conf->pid, SIGSTOP);
        is_stop = 1;
    }
} else {
    // 优先抵扣超用的CPU时间，扣完再判断是否恢复
    if (overuse_time > 0) {
        overuse_time -= (total_cpu_usage - p_total_cpu_usage);
    } else if (cpu_usage < resume_line) {
        kill(conf->pid, SIGCONT);
        is_stop = 0;
    }
}
//*************************

调整后实测，设定20%阈值时，CPU使用率最高不会超过19.8%，不会再出现冲高过线的问题，采样间隔设为10ms时本身的CPU开销可以忽略不计。

内容的提问来源于stack exchange，提问作者liaotonglang