WEBKT

内核压力指标PSL详解与实战教程

8 0 0 0

CPU利用率为何不够用？

在传统运维中我们常依赖top或mpstat输出的CPU使用率来判断系统负载然而在高动态的容器化环境中这一指标常显乏力：

1️⃣ CPU使用率反映的是时间片占用而非真实工作效能——进程可能因等待IO或内存而"空转"导致数值虚高
2️⃣ 无法区分短期尖峰与持续压力易引发误伸缩
3️⃣ 多核环境下平均掩盖了单核瓶颈

这就好比仅凭车速表判断交通拥堵而忽略了路口排队长度

PSL是什么？

Pressure Stall Information简称PSS是一种内置于Linux内核的性能度量机制它量化了由于资源竞争导致的进程"停滞stall"时间

PSL三大核心指标

通过 /proc/pressure/目录可实时读取：

#查看CPU压力
cat /proc/pressure/cpu

#输出示例
some avg10=0.05 avg60=0.03 avg300=0.01 total=12500000  
full avg10=0.01 avg60=0.00 avg300=0.00 total=3500000
  • some表示至少一个任务因资源不足而停滞的比例
  • full表示所有非空闲任务同时停滞的比例
  • avg10/avg60/avg300对应最近10秒60秒5分钟的压力均值

类似地 memory和io子文件分别反映内存与IO压力

PSL计算原理浅析

内核采样周期内当进程就绪却因资源短缺无法执行时累计停滞时间假设采样窗口为500ms其中进程因内存不足等待了50ms则 some值为10%

PSL相比CPUSutilization的优势在哪？

维度 CPUSutilization PSS
响应延迟 间接反映需计算差值 直接测量停滞时长
资源类型 仅CUP覆盖不全 支持CUP内存IO三维度
瓶颈定位 难以区分等待原因 明确指示卡在何种资源
阈值敏感性 波动大易抖动 平滑趋势更适合告警

举例来说当容器因磁盘IO阻塞时CPUS使用率可能很低但PSS的io压力值会飙升这正是触发扩容的关键信号

如何采集PSS数据？

###方案一 |节点级监控

部署 node-exporter配合Prometheus新增采集器：

#prometheus.yml片段
scrape_configs:
job_name:'node'
static_configs:
targets:[localhost9100]
params:
collect[]:[pressure]

启用后可在Grafana中查询 node_pressure_cpu_waiting_seconds_total

###方案二 |容器内直读

对于privileged容器可直接挂载proc文件：

FROMalpine  
RUNapkadd—no-cachestress-ngprocps  
VOLUME/proc/pressure/

运行时通过 cat/proc/pressure/cpu获取实时数据

##实战教程 |基于PSS的KubernetesHPA扩缩容

假设我们已部署Prometheus Stack以下步骤实现自定义指标伸缩：

###Step1安装MetricsAdapter

使用 prometheus-adapter将PSS指标转换为K8S可识别的Custom Metrics：

helmreponameprometheus-comminityhttps://prometheuscommunity.github.io/helm-charts  
helminstallprometheus-adapter\ 
—setprometheus.url=http://prometheus-server.default.svc.cluster.local\
—setrules.custom=true\
prometheus-comminity/prometheus-adapter

###Step2定义规则文件

创建适配器规则映射PSS值：

#custom-metrics.yaml  
rules:
seriesQuery:'{__name__="node_pressure_cpu_waiting_seconds_total",instance="",job="node"}'
resources:
overrides:
instance:
resource:"node"
name:
matches:"^(.*)_total$"
as:"${1}_per_second"
metricsQuery:'rate(<<Series>>[5m])*100'

此规则将原始计数器转为百分比压力值

###Step3验证自定义指标

应返回各节点近5分钟的平均CUP压力百分比

###Step4创建HPAController

针对示例Deployment webapp编写HPA清单：

kindHorizontalPodAutoscaler  
metadata namewebapp-hpa  
spec scaleTargetRef apiVersionapps/v1 kindDeployment namewebapp minReplicas2 maxReplicas10 metrics typePods pods metric namepressure_cpu_waiting_per_second target typeAverageValue averageValue"15"

含义当Pod组平均CUP停滞压力超过15%时触发扩容直至10副本低于阈值后逐步收缩至2副本

##进阶技巧与避坑指南

✅采样频率建议结合业务节奏——高频采集(如1s)适合交易类应用低频(30s)适用于批处理作业

✅多维度组合策略同时监控内存压力避免OOMkill后再扩容为时已晚

✅注意内核版本要求完整功能需≥5.x旧版可能缺失某些子指标

✅压测验证在生产前用 `stressng模拟资源争抢观察PSS变化曲线确认阈值合理性

⚠️切勿单独依赖单一指标推荐将PSS与传统CPUSMemory用量互补形成立体画像

⚠️容器运行时如containerd/docker需启用cgroupv2以获得更准确的per-cgroup压力数据

##结语

从“用了多少”到“卡了多久”PLSI代表的是一种思维范式的转变它让扩缩容决策从粗糙走向精细正如一位资深SRE所说：“真正的性能洞察源于对等待时间的敬畏”在云原生时代掌握PLSI或许就是你优化资源效能的下一块拼图

内核手记 Linux内核性能监控云原生

评论点评