最常见元凶是SCHED_FIFO/SCHED_RR实时调度策略误用，其0–99高优先级无条件抢占普通进程，导致SSH、图形界面等基础服务长期饥饿卡顿，而CPU使用率显示偏低。

Linux 应用卡顿若源于内核调度策略不当，最常见也最隐蔽的元凶是 SCHED_FIFO 或 SCHED_RR 实时调度策略被误用。这类进程拥有 0–99 的高优先级，能无条件抢占普通进程（优先级 100–139）的 CPU 时间，导致图形界面、网络服务、SSH 等基础任务长期得不到调度，表现为“系统响应迟缓”“鼠标卡顿”“终端无响应”，而 top 却显示 CPU 使用率不高——因为卡顿进程实际处于 R（运行）或 D（不可中断睡眠）状态，却因调度器“不给轮到”而无法执行。

检查是否存在实时调度进程

运行以下命令，快速筛选出所有使用实时策略的进程：

• ps -eo pid,tid,cls,pri,nice,comm,args --sort=-pri | head -20 查看 CLS 列：若出现 FF（SCHED_FIFO）或 RR（SCHED_RR），且 PRI 在 0–99 范围，即为嫌疑对象
• chrt -p PID（对可疑 PID 单独验证）：输出类似 sched policy: SCHED_FIFO, sched priority: 50 即确认
• ps -T -p $(pgrep -f "your_app_name") + chrt -p TID：特别注意多线程应用中个别线程被单独设为实时策略的情况

识别调度导致的资源饥饿现象

实时进程本身未必 CPU 占用高，但会压制其他关键服务。观察以下典型迹象：

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

• 桌面环境卡顿，但 top 中 %us 和 %sy 均偏低，%wa（I/O wait）异常升高 → 表明进程在等 I/O，却被实时任务阻塞调度
• SSH 连接响应极慢或超时，systemctl status sshd 显示 active 但无日志输出 → sshd 线程被持续抢占，无法及时处理 socket 事件
• cat /proc/stat 中 procs_running 值长期 > CPU 核数，同时 procs_blocked 显著上升 → 大量进程在就绪队列中排队，却无法获得 CPU 时间片

临时恢复与定位源头

确认问题后，切勿直接 kill -9，先尝试降级调度策略：

• 对单个进程重置为默认调度：chrt -p 0 PID（0 表示恢复正常 CFS 调度）
• 若进程由 systemd 启动，检查其 service 文件：systemctl cat your-service.service，查找 CPUSchedulingPolicy= 或 CPUSchedulingPriority= 配置项
• 排查启动脚本、容器 runtime（如 Docker 的 --cpu-quota 或 --cpus 不会触发实时调度，但 --cap-add=SYS_NICE 可能允许应用自行设置）
• 检查音视频工具（如 JACK、PulseAudio real-time mode）、工业控制软件、自研嵌入式服务等是否启用实时模式且未合理限制作业范围

预防与加固配置

避免同类问题反复发生：

• 生产环境禁用非必要实时权限：echo 'kernel.sched_rt_runtime_us = 0' >> /etc/sysctl.conf && sysctl -p（彻底关闭实时调度带宽，不影响已有进程，仅阻止新实时任务获得 CPU）
• 限制用户实时调度能力：echo '@audio - rtprio 99' >> /etc/security/limits.conf（仅授权特定组有限使用，而非全放开）
• 在 CI/CD 流程中加入静态扫描：grep -r "pthread_setschedparam\|SCHED_FIFO\|SCHED_RR" ./src/，提醒开发者避免硬编码实时策略