第 10 章 进程、信号与资源限制

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

  进程状态机（内核表示）与 ps 单字母的投影

        fork/clone ──▶ TASK_RUNNING (R)  ◀── 被抢占/时间片耗尽（仍是 RUNNING）
                          │   ▲
            等待事件       │   │ 事件到达 或 信号投递
                          ▼   │
              TASK_INTERRUPTIBLE (S) ── 只有事件能唤醒 ──▶ TASK_UNINTERRUPTIBLE (D)
                唤醒条件 = 事件 ∪ 信号                      唤醒条件 = 只有事件
                （磁盘 I/O 完成、NFS RPC、驱动私有等待都落在 D）
  TASK_STOPPED/TASK_TRACED (T)、EXIT_ZOMBIE (Z)、EXIT_DEAD (X) 见下表（ps 会出现 D+/Z+ 这类叠加写法）

1
2
3
4
5

# 1) 一眼看出哪些进程卡在 D；wchan 是它正在等待的内核函数名
ps -eo pid,stat,wchan:24,comm --sort=stat | grep -E '^ *[0-9]+ .* D'
echo w > /proc/sysrq-trigger && dmesg -T | tail -n 200   # 2) 打印所有 D 任务的内核栈，定位 I/O 路径
# 3) 多线程场景：kill 投递给进程，须先找出具体卡住的线程；并交叉验证块设备指标
ps -eLo pid,tid,stat,wchan:20,comm | awk '$3 ~ /D/'; iostat -xz 1 5 | grep -E 'Device|nvme|sd'

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

  虚拟地址空间 VSZ（= statm 的 size，单位页）——把以下全部计入，且含未触碰的页：
  私有匿名映射（堆、线程栈、brk 段）、文件映射（MAP_PRIVATE 只有代码与只读数据，
  写时复制后转私有；MAP_SHARED 如共享库与 mmap 文件）、共享内存段（shmget、tmpfs）
  ──────────────────────────────────────────────────────────────
  物理内存侧（只有真的装了东西才算），恒有 USS ≤ PSS ≤ RSS：
    RSS = 该进程页表中"已驻留"的页数（含与他人共享的页，每人各记满一份）
    PSS = Σ(该进程映射的每个驻留页 ÷ 映射它的进程数)    USS = 只有本进程映射的驻留页
  ⟹ Σ(所有进程 RSS) 会远超物理内存，而 Σ PSS ≈ 物理内存占用

  算例：libc.so 2000 驻留页（其中 500 页另被 2 个进程映射，共 3 个进程）+ 300 私有堆页 + 100 私有栈页，页 4 KiB
    RSS = 2000 + 300 + 100 = 2400 页 × 4 KiB = 9600 KiB ≈ 9.4 MiB（共享页各记满）
    PSS = (1500 + 500/3) + 300 + 100 ≈ 2066.7 页 ≈ 8.1 MiB      （500 页三分摊）
    USS = 300 + 100 = 400 页 = 1600 KiB ≈ 1.6 MiB                （只有独占页）
  ⟹ 排查"谁吃了内存"用 PSS（跨进程不重复），"杀掉它能释放多少"看 USS

1
2
3
4
5
6

# smaps_rollup（4.14+）直接给 Pss/Private_*；逐个读 smaps 单次可达数十毫秒，不适合高频采集
cat /proc/1234/smaps_rollup
#   Rss: 9600 kB（与上面算例一致）  Pss: 8270 kB ≈ 8.1 MiB
#   Private_Clean: 1200 kB   Private_Dirty: 400 kB   Shared_Clean: 7600 kB
# Σ Pss 应接近 free 的 used（差值主要是内核 slab/页表/驱动占用）
grep -H Pss /proc/[0-9]*/smaps_rollup 2>/dev/null | awk '{s+=$2} END{printf "Σ Pss = %d MiB\n", s/1024}'

1
2
3
4
5
6

  两种口径的差异（同一进程：启动后先忙 1 s，之后空闲 59 s）
    均值口径（top 默认）：   1 s / 60 s × 100% ≈ 1.7%   ← 看不出它曾吃满一个核
    区间口径（top -I / pidstat）：忙的那 1 s 内 = 100%，其余 ≈ 0%
  刷新间隔 -d 的影响（逐秒突发 100 ms、其余空闲）：-d 1 可能读到 0%（恰好落在
  空闲窗口），也可能读到约 10%（落在突发窗口）⟹ 间隔越大，短时尖峰越容易被
  平均掉；只看瞬时值的工具甚至完全错过尖峰

1
2
3
4

# 区间口径：pidstat 明确给出"距上次采样"窗口内的 %usr/%system/%CPU
pidstat -p 1234 1 5      # Average:  0 1234  0.20  0.00  0.20  2  java
# top 默认把线程聚合成进程，-H 展开成线程后才能定位是哪条线程在烧 CPU
top -b -H -p 1234 -n 1 | head -n 20

1
2
3
4

  nvcsw 大、nivcsw 小：CPU 没被抢，是进程自己在等 —— 等锁 / 等 I/O / 等下游
    同时 stime 高 → 锁竞争或频繁 syscall（futex 等待也计入 stime）；同时 wa 高 → I/O 等待
  nvcsw 与 nivcsw 都大：既被抢又在让 —— 典型"线程数远多于 CPU 核数"（第 5 章 5.6 节）
  nivcsw 大、nvcsw 小：纯粹的 CPU 争抢 —— 查 CPU 配额（10.6.1 节的 cpu.max）与亲和性

1
2
3
4
5
6

# 取两次增量再相减：进程可能已跑了几十天，累计值无法反映当下
read_stat() { awk '{print $1, $14, $15, $41, $42}' /proc/$1/stat; }
read_stat 1234; sleep 5; read_stat 1234
#   1234 812 340 15210 890  →  1234 815 342 15367 921
# 5 秒内：utime +3 tick(30 ms)、stime +2 tick(20 ms)、nvcsw +157、nivcsw +31
# 解读：CPU 只用了 50 ms 却自愿让出 157 次 → 瓶颈在等待，不在计算

1
2
3
4
5
6
7

# 三个十六进制位图，位 n 对应信号 n+1；判定：掩码 & (1 << (N-1)) 非零 ⟹ 第 N 号信号在集合中
# 例：ShdPnd 的 bit 8（值 0x100）置位 ⟹ 第 9 号信号 SIGKILL 已挂账未投递
grep -E 'SigQ|ShdPnd|SigBlk|SigCgt' /proc/1234/status
#   SigQ: 0/63028           ← 未决+排队信号数 / 该用户上限（RLIMIT_SIGPENDING）
#   ShdPnd: 0000000000000100 ← 进程级未决：有信号挂账没投递（D 态时常见）
#   SigCgt: 0000000180004a03 ← 已装 handler 的信号集合（SIGKILL/SIGSTOP 永不在列）
kill -l                 # 信号名与编号的映射（实时信号显示为 RTMIN+n）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

  fd 限制的五层来源（从系统到进程，逐层收窄）
  ① 内核全局上限：/proc/sys/fs/nr_open（单进程，默认 1048576）、
                  /proc/sys/fs/file-max（全系统 fd 总量，按内存自动计算）
  ② 系统级默认（PAM 登录路径）：limits.conf 与 limits.d/*.conf
        "appuser soft nofile 65535" ⟹ 只对【经由 PAM 登录】的会话生效（ssh/su/login），
        对 systemd 服务、容器、cron 默认【不生效】
  ③ systemd 服务：unit 里的 LimitNOFILE=65535（直接 fork/exec，不经过 PAM，② 对它无效）
  ④ 容器：docker run --ulimit nofile=65535:65535（在③之后由 runtime 设置）
  ⑤ 进程自身：setrlimit()，或 shell 里 ulimit -n 65535（只能降低硬限制）
  ⟹ 唯一能在运行期确认以上全部结果的地方：/proc/PID/limits

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 1) 先看"实际生效值"而不是你设过的值——这是唯一权威来源
grep -E 'Max open files|Max processes' /proc/$(pgrep -f myapp | head -1)/limits
#   Max open files            65535                65535                files
# 2) 已被 systemd 拉起 → 查 unit 覆盖而不是 limits.conf
systemctl show myapp -p LimitNOFILE -p LimitNPROC
# 3) 容器 → 容器内 /proc 看到的就是当前进程的限制
docker exec myapp sh -c 'cat /proc/1/limits | grep -i "open files"'
# 4) 排除系统级上限阻塞：nr_open 必须 ≥ 你想设的值
cat /proc/sys/fs/nr_open; cat /proc/sys/fs/file-nr   # 单进程上限；已分配/空闲/file-max
# 5) 区分"限制"与"泄漏"：fd 数单调增长 ⟹ 泄漏；长期贴上限 ⟹ 限制
ls -l /proc/PID/fd | awk '{print $NF}' | sort | uniq -c | sort -rn | head

1
2
3
4
5
6
7
8
9

  v1：每个控制器一棵独立树（一个进程可同时属于多棵树）
    /sys/fs/cgroup/cpu/mygrp/tasks 、/sys/fs/cgroup/memory/mygrp/tasks ……
    后果：层级不一致，无法原子地对"一个容器"统一限额；同一进程可能在 cpu 树里
          属于 A 组、在 memory 树里属于 B 组
  v2：所有控制器共用一棵统一树（一个进程只属于一条路径）
    /sys/fs/cgroup/mygrp/   ← 一个目录就是"一个容器"，内含 cgroup.controllers
                              （本层可用控制器）、cpu.max、memory.max、io.max 等
    优点：一个层次、一套文件、可原子迁移；"no internal process" 约束强制只有
          叶子节点能放进程，语义更干净

1
2
3
4
5
6

# 先确认在哪棵树：单行 = v2，多行 = v1；由此决定后面读哪些文件
cat /proc/self/cgroup        # 0::/  ← 0:: 是 v2 单一层次的标志
cat /sys/fs/cgroup/cpu.max   # 例如 150000 100000，换算成"几核"：
awk '{if ($1=="max") print "不限"; else printf "%.2f 核\n", $1/$2}' /sys/fs/cgroup/cpu.max
grep nr_throttled /sys/fs/cgroup/cpu.stat   # 非 0 说明应用确实撞过配额墙
grep -E '^(max|oom|oom_kill) ' /sys/fs/cgroup/memory.events   # 是否触顶过

1
2
3

nproc; python3 -c 'import os; print(os.cpu_count())'   # 复现"核数 ≠ 配额"：都是 64（拓扑口径）
cat /sys/fs/cgroup/cpu.max             # 200000 100000 → 实际只有 2 核的带宽
grep nr_throttled /sys/fs/cgroup/cpu.stat   # 跑满线程后该计数持续增长即为撞配额

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

  docker exec：经守护进程 + 运行时，走完整的执行与安全栈
    客户端 → dockerd → containerd → runc 的 "exec" 路径
      ├─ 目标：容器 init 的 namespace 集合（从容器元数据读取）
      ├─ 进入：setns() 逐类进入 + 设置 cgroup 归属
      ├─ 附加：应用容器的 seccomp/AppArmor/SELinux、注入配置的环境变量、选用户
      └─ 结果：受容器安全策略约束；依赖守护进程；无法用于非容器进程
  nsenter：直接对已有 PID 调用 setns()，工具本身做主
    nsenter -t <PID> -m -u -i -p -n [-U --setuid --setgid]
      ├─ 只做两件事：setns() 进入指定 namespace + exec 目标程序；不读容器元数据、
      │  不应用 seccomp/AppArmor、环境变量默认取调用者的
      └─ 结果：宿主 root（或 CAP_SYS_ADMIN）即可用、不依赖 dockerd，因而在容器
                【没有】调试工具的 distroless 镜像里特别有用