返回第三卷 · 进程与系统调用：03.02 · Linux 资源：03.03 · CPU 调度：03.04 · 内存与 RSS：03.06

03.11 隔离与限制：主机空闲为何 IM 网关容器仍超时

DeepTutor 八节初稿经技术与教学审阅后的静态课程。主机、容器、CPU、内存、OOM 和网关结果均为虚构纸上读数；没有运行 Go、IM、容器实验、部署、压测或站点。当前 S2 /v1 仍是正文非空且最多 6 UTF-8 B、原始 HTTP 请求正文最多 4096 B、同 ID 重复 409、非成员目标隐藏 404、200 accepted_in_memory 仅代表本进程内存受理；未来 S3 /v2 stored_in_teaching_db 是提议且仍为 6 B，R9 6→9 B 待审。09.02 当前合同

一、先给每个“资源不足”标观察范围

11.04–11.05 已教我们区分工作负载、CPU 核秒、等待、Go 堆与 RSS。现在设一个纸上未来网关：宿主机有 8 核，整机 CPU 图显示约 10%；网关所在 cgroup v2 的 cpu.max 却是 50000 100000，一秒内该组使用 0.48 核秒，同时 CPU 节流计数上升，A 在假想 S2 /v1 接口等待受理 200 的 P95 变长。两张图并不矛盾：前者按整台主机 8 核作分母，后者按网关组约 0.5 核额度作分母。Linux cgroup v2：CPU 控制

宿主机：8 核，总 CPU ≈10%（含其他进程）
网关 cgroup：cpu.max = 50000 100000 → 50ms/100ms ≈ 0.5 核平均额度
该组一秒用量：0.48 核秒 → 0.48/0.5 = 96% 的纸上额度
业务症状：A 收到内存受理回应的 P95 变长（仍待查原因）

网关的 0.48 核秒只占宿主 8 核一秒总容量的 0.48/8=6%；整机 10% 还可包含其他进程，故“宿主 CPU 低”不能排除该组接近配额。反过来，96% 配额使用 + 节流上升也未单独证明 P95 变长全由 CPU 限制造成；还要看同一窗口的请求率、可运行等待、队列、数据库/网络与用户结果。11.04 假设与反证

初学者先记住三种范围：进程是运行 Go 程序及其线程/地址空间的对象；namespace 让一组进程看到不同的 PID、挂载点或网络等视图；cgroup 汇总/控制一组任务的资源。日常口中的“容器”通常组合这些内核机制与文件系统/运行时配置，不是自动独占一台物理机，也不意味着所有资源读数的分母相同。Linux namespaces(7)

二、namespace 改“看见什么”，不直接给 CPU 额度

Linux namespace 是内核提供的视图隔离。同一个宿主内核可以让不同进程集合看到不同编号、挂载树和网络对象；它不直接规定“最多用 0.5 核”或“内存最多 512 MiB”。Linux namespaces(7)

namespace	改变进程看到的主要对象	IM 网关的初学者反例
PID	进程编号与父子可见范围	容器里 PID 1 通常不是宿主 PID 1；宿主仍可有另一编号指向该进程
Mount	挂载点/路径视图	容器内 /data 不必是宿主相同路径或同一持久卷
Network	网卡、地址、路由、端口等网络视图	容器内 127.0.0.1 是该网络 namespace 的回环，不自动是宿主的服务
UTS	主机名等标识	容器看到自己的 hostname 不意味着有独立物理主机
User	用户/组 ID 映射与权限边界	容器里显示 UID 0 不自动等同宿主不受限的 root

PID namespace 使同一进程在不同层级可有不同 PID；网关日志若只记“PID 1”，从宿主排查时还需结合容器/namespace 身份。网络 namespace 的回环解释“容器里能连 127.0.0.1:port、宿主或另一容器却连不上”：端口发布、路由与服务监听地址都要另查。Mount namespace 则提醒我们日志或配置路径可能来自不同挂载，不能仅凭容器里文件名断定宿主持久位置。Linux PID namespaces

namespace 是隔离构件，不是完整的安全保证。文件权限、用户映射、capability、系统调用限制、网络策略、宿主内核与卷配置仍影响边界；本章只建立机制模型，第十二卷再讨论容器镜像与运行环境。做真实排障时先固定“从宿主读、从容器读、还是从某个进程所在 namespace 读”，不要把不同视图的 localhost、PID 或路径硬拼成一个现场。

三、cgroup v2：CPU 带宽、使用与节流

在本题假设的 cgroup v2 中，cpu.max 的两个数表示一个周期内最多可用的 CPU 时间。50000 100000 是每 100,000 微秒周期可用 50,000 微秒 CPU 时间，长期平均约 0.5 核；它不表示只能固定跑在“半个物理核”，任务可能短时在不同核上执行，再因组带宽耗尽等待下一周期。祖先 cgroup 与其它调度约束也会影响实际可用资源。Linux cgroup v2：cpu.max

cpu.stat 的 usage_usec 是累计 CPU 使用微秒，比较两次快照差值才得到窗口内核秒；nr_throttled/throttled_usec 等字段表示相应带宽节流事件与时间，字段可用性取决于控制器和环境。纸上若一秒 usage_usec 增 480,000，是 0.48 核秒；不要把累计总值 480,000 写成“480,000 微秒/秒”而不写窗口，也不能从一个 nr_throttled=42 快照判断本分钟新增多少。Linux cgroup v2：cpu.stat

Go 的 GOMAXPROCS 决定同一时刻可并行执行 Go 代码的数量，不是 cpu.max 配额、CPU 亲和性、goroutine 数或宿主核数。即使程序可并行跑两个 Go 任务，cgroup 仍可能在 0.5 核平均额度下被节流；随意把 GOMAXPROCS 调大也不会替容器增加 CPU 带宽。具体运行时默认值随 Go 版本与环境可能变化，诊断时记录实际 Go 版本、设置和 cgroup 读数，不从文件名推默认行为。05.05 Go 调度

纸上证据	可说什么	不能单独说什么
宿主 CPU 10%	整机此窗口总体使用不高	网关一定没有 CPU 限制
组使用 0.48/0.5 核秒	接近本题组带宽	P95 恶化唯一根因必为 CPU
节流增量上升	该组出现带宽等待	每次超时都恰好由这次节流造成
Go 堆稳定	某口径下存活对象未明显增长	cgroup 总内存或 socket 内存一定安全

四、memory.current、memory.max 与 OOM 不是 Go 堆曲线

再给一个纸上内存窗口：memory.max=512 MiB，memory.current=500 MiB，之后 memory.events 中 oom_kill 比前次快照增 1。memory.current 是该 cgroup 及后代的当前记账总量，可能含匿名内存、页缓存、内核结构和 TCP socket 缓冲；它不是某个 Go 进程的堆存活量，也不等于该进程 RSS。达到 memory.max 附近可能先触发回收；不能从“500/512 很近”直接推定已杀进程。oom_kill 增量才是本题该范围有进程被 OOM killer 杀掉的更直接事件证据，还要核对哪个进程、何时、是否有上层重启。Linux cgroup v2：memory.current / memory.events

名称	观察主体	解释边界
Go heap in-use	Go 运行时的存活堆样本	不覆盖全部进程内存、同 cgroup 其他进程或内核记账
进程 RSS	一个进程的驻留物理页	不等于 cgroup 中所有后代和 socket/页缓存账
memory.current	cgroup 及后代的当前内存记账	不是“Go 堆已经泄漏 500 MiB”
memory.max	该组硬上限配置	接近上限不等于必然 oom_kill
memory.events 差值	high/max/oom/oom_kill 等事件计数变化	max 增加与确有进程被杀是两种证据

Go 的 GOMEMLIMIT 或 debug.SetMemoryLimit 是Go 运行时管理内存的软限制，不是 cgroup 的 memory.max，也不保证总 RSS 低于该数；外部映射、其他进程以及部分内核记账不由 Go GC 控制。把 GOMEMLIMIT 直接设成 512 MiB、忽略非 Go 和容器其它内存，不能保证不 OOM；设得过紧还可能让 GC 更频繁，增加 CPU 与延迟。应在 11.05 所学分配/存活/RSS 与 cgroup 视角之间建立对照，再由证据决定实验。Go GC Guide：软内存限制 · 11.05 CPU/内存

五、pids、描述符和连接数别混为一个“容器上限”

cgroup v2 pids.max 限制的是该组可创建的内核任务数量，Linux 文档在这里按 TID 计；它不是最大在线连接数。Go 网关可能有很多 goroutine/连接，却只有较少操作系统线程；反过来创建过多线程/子进程可能触到 pids 限制，即使连接数不高。要查 pids.current、pids.events 增量和进程/线程状态，再判断是否真由此导致创建失败。Linux cgroup v2：PIDs 控制器

文件描述符 FD 是进程用来引用打开文件、socket 等内核对象的编号；连接通常要占 socket FD，但 pids.max 不控制 FD。进程 RLIMIT_NOFILE、宿主/容器运行时设置和实际 FD 使用量是另一条证据链。某网关报“too many open files”时，不应因为 pids.current 很低就排除描述符耗尽；也不能因为 pids.max=1024 就宣称“最多 1024 条 WebSocket”。下一章 03.12 将把描述符、磁盘满、信号退出接成资源故障案例。03.03 描述符前置

网络 namespace 又给 socket 排查加了一层：同一监听端口可出现在不同网络视图；从宿主看连接与从容器看连接，需注明 namespace、时间窗及是否经过端口映射/代理。真实环境的只读调查应使用有权限的进程和资源视图，不为取指标随意进入他人的 namespace 或读取私有消息。

六、资源事件回到 S2 用户结果与恢复事实

假设纸上网关进程在 oom_kill 后退出，长连接会断开、A 的请求可能超时或收到连接错误；当前 S2 accepted_in_memory 只承诺本进程内存受理，进程退出后不能从这个 200 推出消息仍可恢复。若一次 POST 已内存受理而响应丢失，客户端以同 ID 重试可能得到 409，或在进程状态丢失后进入另一结果；具体要按同一教学实现的状态与有权查询核对，不能用“重启成功”替代消息事实。未来 S3 的权威 DB 提议是另一个确认点，尚不能倒灌成当前承诺。09.04 响应丢失 · 11.01 成功层级

用户/系统观察	需要核对的资源证据	业务恢复门
A 的受理回应 P95 变长	同窗 cpu.max、使用/节流差、请求与队列	当前 6 B/409/404/200 行为与尾延迟一起回归
网关连接突然下降	memory.events oom_kill、进程退出、socket/网络视图	客户端能重连，旧状态如何查询或补拉
Go 堆看似不高但内存逼近限额	cgroup memory.current/stat、RSS、页缓存/socket	限额/队列/非 Go 占用有解释，不能只看 GC

一个同窗相关的节流或 OOM 事件仍需与相同实例、相同版本和用户尝试对应。若 CPU 配额节流在 A 的慢请求之后才出现，或慢请求集中在另一个实例，就应降低该假设的权重；若没有 oom_kill 变化但网关重启，则要另查信号、健康检查、部署和进程退出码。03.10 只读诊断

七、先读证据与回退门，再讨论调整限额

未来有权限的隔离验证可按这一顺序做：固定业务症状与分母 → 固定宿主/namespace/cgroup/进程作用域 → 两次快照看增量 → 列竞争假设 → 选择一项可逆改动 → 同负载核对用户结果、拒绝和重连。不能因为宿主 CPU 空就盲加网关，不能把 GOMEMLIMIT 调高当作已解决 cgroup OOM，也不能把进程重启当作 S2 消息恢复。资源限制调整需要实例级权限与容量/隔离风险评审，本页只给纸上决策框架。11.04 诊断闭环

本章可用的只读线索包括 /proc/<pid>/ns/ 的 namespace 链接、所处 cgroup 路径、对应 cgroup v2 的 cpu.max/cpu.stat、memory.current/memory.max/memory.events、pids.current/pids.events。路径映射与文件可用性随环境变化，示例不是本机输出。记录两个快照的时间差、单位和后代范围，避免将一个累计值或宿主总值当作容器瞬时结果。Linux namespaces(7) · Linux cgroup v2

固定 openimsdk/open-im-server 提交 f6411a8a1a31d3df36f4c2b3ad28481a94141e1f 的 send.go 选定分支调用 MsgToMQ 后返回；另一 Mongo 消费路径调用 BatchInsertChat2DB。两处只说明所读发送/消费边界，不能证明 OpenIM 真实的 namespace、cgroup、CPU/内存配额、OOM 行为或设备恢复。OpenIM 阅读地图

八、22 道分层练习：写一张容器资源诊断单

先手算作用域与单位，再解释为何资源图不能单独证明用户结果。

基础 1–8：视图与控制

1. namespace 直接设置 CPU 最多 0.5 核吗？

不直接设置。namespace 隔离对象视图；本题 CPU 带宽来自 cgroup cpu.max。

2. 容器内 PID 1 一定是宿主 PID 1 吗？

不一定。PID namespace 可给同一进程不同视图编号。

3. 容器内 `127.0.0.1` 默认是宿主服务吗？

不是。它指该进程所在网络 namespace 的回环。

4. Mount namespace 会改变什么？

进程看到的挂载点/路径视图；相同路径名不必指同一宿主存储位置。

5. 容器里 UID 0 自动拥有宿主所有权限吗？

不自动。用户映射与权限/capability 等机制仍需核对。

6. cgroup `pids.max` 可直接当最大 WebSocket 数吗？

不能。它限制内核任务创建，不是 socket/连接或 FD 数。

7. Go `GOMAXPROCS` 是容器 CPU 配额吗？

不是。它约束 Go 代码可同时执行的并行度，配额由 cgroup 等资源设置决定。

8. 当前 S2 200 表示进程重启后消息一定仍在吗？

不能。它仅承诺本进程内存受理。

算式 9–16：同一窗口比较

9. `cpu.max=50000 100000` 对应长期平均多少核？

50000/100000=0.5 核的带宽额度。

10. 一秒 `usage_usec` 增 480000，是多少核秒？

0.48 核秒；usage_usec 需取两次快照差值。

11. 本题 0.48 核秒与 0.5 核额度相比占多少？

0.48/0.5=96%。

12. 0.48 核秒相对宿主 8 核一秒容量占多少？

0.48/8=6%；宿主总 CPU 10% 可含其他进程。

13. `memory.current=500 MiB` 等于 Go 存活堆 500 MiB 吗？

不等于。它含该 cgroup 及后代的多类内存记账，不是单进程 Go heap。

14. `memory.max=512 MiB`、current=500 MiB，能断定已经 OOM kill 吗？

不能。接近上限不等于有进程被杀，须看事件增量和进程状态。

15. `memory.events oom_kill` 增 1 能支持什么？

该 cgroup 记账范围有一个进程被 OOM killer 杀的事件；还需核对具体进程与业务影响。

16. `GOMEMLIMIT` 可保证 cgroup current 不超过 memory.max 吗？

不能。它是 Go 运行时管理内存的软限制，不控制所有进程/内核记账。

决策 17–22：从资源恢复到业务恢复

17. 宿主 CPU 10% 就能排除网关 CPU 配额瓶颈吗？

不能。按网关 cgroup 配额/使用/节流和同窗请求证据判断。

18. 节流增加与 P95 上升同窗就证明唯一根因吗？

不能。还要排除队列、I/O、其他实例与负载变化，并用反证核对。

19. Go 堆低、cgroup 内存高时还应看什么？

其他进程/后代、RSS、页缓存、socket/内核内存及 memory.stat/events。

20. 网关被 OOM 杀后，连接恢复就能宣布旧 S2 消息恢复吗？

不能。当前 S2 仅内存受理，须核对旧请求状态、客户端重试与有权查询。

21. OpenIM 两处源码能证明它的真实 cgroup 配额或 OOM 吗？

不能。只看到选定发送与 Mongo 消费边界。

22. 一张可复核诊断单至少交什么？

业务确认点、版本/负载、宿主/namespace/cgroup/进程范围、窗口差值、竞争假设、OOM/退出证据、单一可逆改动与用户恢复门。

本章完成标准与后续路径

能区分 namespace 视图与 cgroup 限额，手算 0.5 核额度和 96% 使用，说明 memory.current/Go 堆/RSS 与 oom_kill 的不同证据范围，并把网关节流或退出后的连接/消息恢复写成独立业务验收，才算完成第一轮。本章没有执行任何容器或资源实验。下一章03.12 资源故障案例将用描述符耗尽、磁盘满和信号退出把机制接成完整诊断，再进入第十二卷的平台运行课程。