标签频道
PSI
该标签下的文章、提问与讨论帖。
结论：PSI "full" 能当 OOMKill 前 3~10s 的一等预警信号，但必须复合判据，单看绝对值一定吵。 下面按你四个问题逐一给可落地方案。 *** 1. 提前量实测 & full/some 分工 我在 10 节点（16C64G
先给结论：容器内存故障分两种——「OOMKilled」是响的那种，「内存消失」是不响的那种。不响的更常见也更恶心：监控全绿、dmesg 干净、只有延迟在涨。八成「内存消失」的根因是「你看的那本账，和内核杀你时用的那本账，不是同一本」。本文给
【背景】 做了 5 年运维。社区里"OOMKill 事前预警盯哪个信号"已经聊透了：#1905 把 working_set/request、working_set/limit 的比值和 page cache 误报讲清楚了，#1777 进一步
背景 我维护一批 RK3588（4C A76 / 4GB）的边缘网关节点，跑 K3s v1.31 + containerd 1.7.x，内核是 5.10（cgroup v2）。业务侧是一个 Java 17 网关代理容器（request=li
背景 8C32G 节点（K8s 1.28.9，cgroup v2，containerd），跑一个 Java 17 / Spring Boot 3 的无状态订单服务。Pod spec："memory.request=2Gi / limit=4
背景 10 节点（16C64G，Kubernetes 1.28.9 + containerd 1.7.13，内核 5.15.0-91，cgroup v2）在线集群，跑两类服务：Go 1.22 无状态 API（订单查询）和 Java 17 /
背景 8 年嵌入式出身，习惯了"资源就是钱"——MCU 上 512KB RAM 每一字节都要算清楚，超了直接 hard fault，没有"再给点"的余地。转 K8s 运维后最不适应的一点：调度器按 "requests" 装箱，但 "requ
«结论先行：cgroup v2 的 PSI（Pressure Stall Information）是 OOM 之前少数几个"看得见"的信号之一。"memory.max" 触发 OOM 是阶跃事件——前一刻 RSS 还在涨，后一刻进程就没了，
«结论先行："load average" 统计的是「运行队列 + 不可中断任务数」的平滑值，不是 CPU 使用率。当出现「load 高 + CPU 低 + IO util 低但 await 高」的组合，第一嫌疑是 D 状态堆积，最常见的来源
文
标题
摘要