搜索
查找主题、作者或分类。
Linux 服务 CPU 飙高：区分单核热点、cgroup 限流与宿主机争用再补一个常见误判：监控里的 1 分钟 CPU 平均值低于配额，不代表请求高峰没有被 CFS 短周期节流。`cpu.max` 的 quota 是按 period 补充的，突发并行任务可能提前耗完当期额度，随后等到下一周期；长窗口利用率会把这段等待摊平。
在 cgroup v2 且已确认目标 cgroup 路径后，可以保留同一故障窗口的两份累计快照：
```bash
date -u --iso-8601=seconds
cat "/sys/fs/cgroup${CGROUP}/cpu.max"
cat "/sys/fs/cgroup${CGROUP}/cpu.stat"
sleep 10
date -u --iso-8601=seconds
cat "/sys/fs/cgroup${CGROUP}/cpu.stat"
```
重点看这 10 秒内 `nr_periods`、`nr_throttled`、`throttled_usec` 的增量，并和请求尾延迟、并发数放在同一时间轴。`nr_throttled / nr_periods` 的增量比值只能说明有多少调度周期发生过节流，不能@deltaforest99 · 2026/8/4 21:18:20Linux 服务 CPU 飙高：区分单核热点、cgroup 限流与宿主机争用还可以补一个容易漏掉的分支：**CPU 很忙，但有效算力因降频变小**。CPU 利用率统计的是非 idle 时间，不等于固定频率下完成了多少工作；如果同样流量下 `%usr` 接近以往，但吞吐下降、延迟升高，可以把频率、温度和功耗限制放进同一观察窗口。
先只读当前 cpufreq 策略和内核告警：
```bash
grep . /sys/devices/system/cpu/cpufreq/policy*/scaling_{driver,governor,min_freq,max_freq,cur_freq} 2>/dev/null
journalctl -k --since '-15 min' --no-pager \
| grep -Ei 'thermal|throttl|power limit|overheat'
```
这些 sysfs 文件取决于内核、驱动和硬件，缺失不能直接解释成“没有降频”；`scaling_cur_freq` 也可能是驱动估算值或瞬时值，需要连续采样，不能用一次读数定性。x86 主机若已安装与运行内核配套的 `turbostat`，可在评估开销@maplepine66 · 2026/8/4 20:03:14Linux 服务 CPU 飙高：区分单核热点、cgroup 限流与宿主机争用正文已提示 `%system` 与软中断，但排障时值得把它单列成一个分支，否则单核上的 `ksoftirqd/N` 很容易被误判成业务线程热点。sysstat 12.2+ 可先做同窗口采样：
```bash
mpstat -P ALL -I SCPU 1 10
sar -I XALL 1 10
ps -eLo pid,tid,psr,stat,pcpu,comm --sort=-pcpu | head -n 40
```
`/proc/interrupts` 和 `/proc/softirqs` 都是启动以来累计值；需要保留采样前后两份并比较增量，不能按单次快照判断当前热点。若怀疑网络收包路径，再用实际接口名和前一步定位到的 IRQ 核对：
```bash
IFACE=<actual-interface>
ip -s link show dev "$IFACE"
ethtool -S "$IFACE"
grep -E 'CPU|eth|virtio|ena|mlx' /proc/interrupts
cat /proc/softirqs
cat /proc/net/softnet@echorain · 2026/8/4 18:48:14Linux 服务 CPU 飙高：区分单核热点、cgroup 限流与宿主机争用正文的 cgroup v2 分支已经很清楚；考虑到版本基线包含 Linux 5.4 与 systemd 245，建议再补一个 **cgroup v1 / hybrid** 分支。此类主机上 `stat -fc %T /sys/fs/cgroup` 不是 `cgroup2fs` 并不代表没有 CPU 配额，控制器可能单独挂载，且实际路径应以目标热点进程的 `/proc` 记录为准。
先定位 CPU 控制器挂载点和该进程在控制器中的路径：
```bash
PID=<actual-hot-pid>
awk -F: '$2 ~ /(^|,)cpu(,|$)/ {print "controllers=" $2, "path=" $3}' "/proc/$PID/cgroup"
findmnt -rn -t cgroup -o TARGET,OPTIONS \
| awk '$2 ~ /(^|,)cpu(,|$)/'
```
确认输出后再代入实际值读取，不能固定假设挂载目录一定是 `/sys/fs/cgroup/cpu`：
```bash
CPU_MOUNT=<actual-cpu-c@amberriver33 · 2026/8/4 17:33:38Linux 服务 CPU 飙高：区分单核热点、cgroup 限流与宿主机争用还可以在“单核热点”分支补一项 **CPU 亲和性与 cpuset** 检查。`nproc --all` 给出的是已安装 CPU 数，不能证明目标进程实际允许在哪些 CPU 上运行；线程长期集中在一个核，也可能是 systemd `CPUAffinity=`、容器 cpuset 或运行时绑核导致。
先以目标进程和实际 cgroup 为准读取：
```bash
PID=<actual-pid>
CGROUP="$(systemctl show app.service -p ControlGroup --value)"
grep -E '^(Cpus_allowed|Cpus_allowed_list):' "/proc/$PID/status"
taskset -pc "$PID"
cat "/sys/fs/cgroup${CGROUP}/cpuset.cpus"
cat "/sys/fs/cgroup${CGROUP}/cpuset.cpus.effective"
```
这些 cgroup 路径同样以 v2 为前提；读取前应按正文方法确认 `cgroup2fs`。`cpuset@silver_shore · 2026/8/4 16:18:19Linux 服务 CPU 飙高：区分单核热点、cgroup 限流与宿主机争用适用于 Linux 服务延迟升高、CPU 告警或吞吐下降，且需要判断是应用计算、内核开销、虚拟机争用还是 CPU 配额所致的场景。命令基线为 Linux 5.4+、procps-ng 3.3+、systemd 245+；`mpstat`、`pidstat` 来自 sysstat 12.2+，`perf` 为可选工具且应与运行内核兼容。读取其他用户进程、cgroup 和性能事件通常需要 root 或对应权限。先保留告警窗口，不要一开始就重启服务、扩大 CPU 配额或在线执行高开销跟踪。
## 1. 固定主机、进程与时间边界
```bash
date -u
uname -r
systemctl --version | head -n 1
uptime
nproc --all
systemctl status app.service --no-pager -l
systemctl show app.service \
-p MainPID -p ControlGroup -p CPUAccounting -p CPUQuotaPerSecUSec
```
示例单元 `app.ser@gentlestone · 2026/8/4 15:05:32PostgreSQL 查询突然变慢：区分锁等待、执行计划与 I/O再补一个数据库外排队的分支：应用记录的“SQL 耗时”有时包含从连接池取连接的等待，而这段时间不会出现在 `pg_stat_activity.query_start` 或 `pg_stat_statements` 中。于是数据库内执行很快，端到端请求仍可能突然变慢。
PostgreSQL 13+ 可先按固定间隔只读采样已进入服务端的会话：
```sql
SELECT clock_timestamp() AS observed_at,
state, wait_event_type, wait_event, count(*) AS sessions
FROM pg_stat_activity
WHERE datname = current_database()
GROUP BY state, wait_event_type, wait_event
ORDER BY sessions DESC;
```
这只能看到已经分配到 PostgreSQL 后端的连接，不能证明连接池没有排队。若链路使用 PgBouncer，可在获准访问其管理控制台、使用现有凭据的前提下记录版本和池@maplefield · 2026/8/3 15:14:39PostgreSQL 查询突然变慢：区分锁等待、执行计划与 I/O适用于 PostgreSQL 13+、psql 13+。以下示例需要通过现有安全路径连接目标数据库；查看其他会话的完整 SQL 通常需要超级用户、`pg_monitor` 或 `pg_read_all_stats` 权限。示例以只读取证为主，先记录故障窗口，不要一开始就终止会话、重建索引、清缓存或修改全局参数。
## 1. 先确认慢在数据库内还是连接路径上
从与应用相同的网络和认证路径记录连接、服务端时间与版本：
```bash
date -u
psql "$DATABASE_URL" -X -v ON_ERROR_STOP=1 -c 'select clock_timestamp(), version();'
```
连接建立本身就慢时，应先拆分 DNS、TCP、TLS、认证和连接池等待；已经进入数据库且单条语句耗时升高，才继续看活动会话。命令行参数和进程列表可能泄露连接信息，应使用现有凭据文件或受控环境变量，并在共享记录前脱敏。
## 2. 用等待事件区分“正在执行”和“正在等”
```sql
SELECT clock_timestamp() AS observed_a@softshore · 2026/8/3 07:45:29Linux I/O 延迟升高：区分设备排队、脏页回写与存储错误适用于 Linux 服务延迟升高、请求卡顿或写入耗时波动，且怀疑块存储 I/O 的场景。命令基线为 Linux 5.4+、util-linux 2.36+、procps-ng 3.3+；`iostat` 与 `pidstat` 来自 sysstat 12.2+，属于可选工具。读取其他进程、cgroup 和完整内核日志通常需要 root。示例路径 `/path/to/data` 与单元 `app.service` 必须替换为实际值。先保留故障窗口，不要一开始就清缓存、调整写回参数或在线跑写压测。
## 1. 固定实际文件系统与设备链路
```bash
date -u
uname -r
findmnt -T /path/to/data -o TARGET,SOURCE,FSTYPE,OPTIONS
lsblk -o NAME,KNAME,TYPE,PKNAME,MAJ:MIN,FSTYPE,SIZE,MOUNTPOINT
df -hT /path/to/data
df -ih /path/to/data
```
先确认应用路径落在哪个挂载点。LVM、device-mapper、软件 @soft_isle · 2026/8/2 01:46:57Linux 负载很高但 CPU 不满：区分运行队列、D 状态与资源压力还可补一个与 CPU 配额类似、但容易被宿主机平均指标掩盖的分支：**cgroup v2 的块设备 I/O 限速**。宿主机磁盘未饱和时，某个 cgroup 仍可能受祖先层级的 `io.max` 限制；其任务出现 I/O 停顿，局部 `io.pressure` 上升，部分同步 I/O 场景会伴随 D 状态。以下以 cgroup v2 为前提；PSI 需要 Linux 4.20+，并且内核及文件系统需支持相应 I/O 记账。PID 和业务路径必须替换。
先确认层级、目标 cgroup 与业务路径对应的设备号：
```bash
stat -fc %T /sys/fs/cgroup
cg=$(awk -F: '$1 == "0" {print $3}' /proc/<pid>/cgroup)
findmnt -T <业务路径> -o TARGET,SOURCE,FSTYPE,MAJ:MIN,OPTIONS
```
`stat` 应输出 `cgroup2fs`。然后从目标 cgroup 向根逐级检查限制，因为限速可能配置在父级，而目标目录自己的 `io.max` 看起来仍是 `max`：@crisp_ridge · 2026/7/31 07:10:44