📚 课程目录第1章性能检测概述

1. 性能检测概述：为什么需要实时性能检测？

大家好，我是这门课的主讲。今天咱们聊聊一个很基础、但很多人其实没想透的问题——为什么非要实时检测性能？

我见过不少团队，项目上线前跑一遍压测，看着数据还行，就拍胸脯说「没问题」。结果上线第二天，用户一多，CPU 直接飙到 95%，接口超时一片红。你说这时候再去看日志、查监控，是不是已经晚了？

说白了，实时性能检测就是给系统装一个「心电图」。平时看着正常，一旦心率异常，立刻报警。你想想看，一个心脏病人要是等晕倒了才去医院，那跟咱们等系统挂了才去排查，有什么区别？

  核心观点：实时检测不是「锦上添花」，而是「雪中送炭」。它让你在用户骂娘之前，就把问题掐死在摇篮里。

1.1 实时检测到底解决什么问题？

我把它总结成三个场景，你对照一下自己的项目，看看中了几个：

突发流量冲击——比如双十一、秒杀活动，流量瞬间翻几十倍。没有实时检测，你连「什么时候扛不住」都不知道。
内存泄漏慢慢耗死系统——我遇到过最坑的一次，一个 Java 服务跑了 3 天，GC 越来越频繁，最后 Full GC 把 CPU 吃满。实时看内存曲线，一眼就能发现「锯齿越来越密」。
慢 SQL 拖垮数据库——有时候不是代码写得烂，是某个查询没走索引。实时检测能告诉你：哪个 SQL 在「偷」你的 IO 时间。

嗯，这里要注意：实时不是「每秒刷一次」就叫实时。真正的实时检测，是检测频率能跟上系统变化的速度。比如 CPU 可以 1 秒采一次，但内存 GC 可能 10 秒看一次就够了。

1.2 四大核心指标：CPU、内存、IO、网络

咱们一个一个说。这四个指标，就像汽车的四个轮子，哪个爆了车都跑不了。

指标	核心关注点	常见异常表现	我常用的检测工具
CPU	使用率、负载、上下文切换	使用率持续 > 80%，负载 > 核数	top, perf, /proc/stat
内存	使用量、GC 频率、Swap	GC 间隔越来越短，Swap 持续增长	free, vmstat, jstat
IO	磁盘读写延迟、IOPS、队列长度	await > 30ms，队列深度 > 2	iostat, iotop, /proc/diskstats
网络	带宽、丢包率、连接数、延迟	丢包率 > 0.1%，TIME_WAIT 堆积	netstat, ss, tcpdump

一个小技巧：我习惯把 CPU 和内存放在一起看。因为很多时候 CPU 高是内存 GC 引起的，单看一个指标容易误判。

1.3 CPU 指标深度解读

CPU 使用率大家都会看，但「负载」很多人理解错了。负载不是使用率，而是「排队等待 CPU 的进程数」。举个例子：

4 核机器，负载 4.0 —— 说明 CPU 刚好跑满，没有排队
4 核机器，负载 8.0 —— 说明有一半进程在排队，系统已经过载了

我曾经遇到一个案例：某服务 CPU 使用率只有 60%，但负载飙到了 12。查了半天，发现是大量线程在等一把锁，锁释放慢，线程全堵住了。你看，只看使用率根本发现不了问题。

避坑指南：我曾经在线上用 top 看 CPU，发现某个进程使用率 200%（多核），以为正常。后来才发现是死循环导致的。记住：CPU 使用率超过核数 × 80% 就要警惕。

1.4 内存指标：别等 OOM 才后悔

内存检测最怕什么？OOM（Out Of Memory）。但 OOM 不是突然发生的，它有一个过程。我总结了一个「三步排查法」：

看总量——free -m 看剩余内存，如果持续低于 10%，就要注意了
看进程——top 然后按 M 排序，找出吃内存最多的进程
看 GC——如果是 Java 应用，jstat -gcutil 看 GC 频率。YGC 间隔小于 1 秒，基本就是内存泄漏了

我记得有一次，一个同事说「内存还剩 2G，没事」。我让他看看 Swap 使用量，结果 Swap 已经用了 4G。这说明物理内存早就吃完了，系统在拿磁盘当内存用，性能能好才怪。

1.5 IO 和网络：容易被忽略的「隐形杀手」

IO 和网络的问题，往往不像 CPU 那么直观。但它们的破坏力一点不小。

IO 方面，我最关注两个值：

await：IO 请求的平均等待时间。超过 30ms 说明磁盘性能跟不上了
svctm：实际服务时间。如果 svctm 接近 await，说明磁盘本身慢；如果 await 远大于 svctm，说明排队严重

网络方面，我踩过一个坑：某服务接口偶尔超时，查了代码、查了数据库，都没问题。最后用 tcpdump 抓包，发现是 TCP 重传率高达 5%。原来是网络交换机有问题，丢包严重。你看，网络问题有时候比代码问题更难定位。

1.6 知识体系总览

下面这张图，把咱们这一章的核心内容串起来了。你可以把它当成一个「实时性能检测的知识地图」：

1.7 一个简单的实时检测脚本

光说不练假把式。我写了一个最简单的 shell 脚本，每秒采集一次 CPU 和内存数据。你可以先跑起来感受一下：

#!/bin/bash
# 最简单的实时检测脚本
# 每秒采集 CPU 和内存数据

while true; do
  # 采集时间戳
  TIMESTAMP=$(date +"%Y-%m-%d %H:%M:%S")
  
  # CPU 使用率（取 idle 列，用 100 减）
  CPU_IDLE=$(top -bn1 | grep "Cpu(s)" | awk '{print $8}' | cut -d'%' -f1)
  CPU_USAGE=$(echo "100 - $CPU_IDLE" | bc)
  
  # 内存使用率
  MEM_TOTAL=$(free -m | grep "Mem:" | awk '{print $2}')
  MEM_USED=$(free -m | grep "Mem:" | awk '{print $3}')
  MEM_USAGE=$(echo "scale=2; $MEM_USED * 100 / $MEM_TOTAL" | bc)
  
  # 输出
  echo "$TIMESTAMP | CPU: ${CPU_USAGE}% | MEM: ${MEM_USAGE}%"
  
  sleep 1
done

试试看：把这个脚本跑起来，然后开一个浏览器多刷几次页面。你会发现 CPU 和内存的曲线会跟着波动。这就是「实时检测」的雏形。

当然，这个脚本太简陋了，生产环境肯定不能用。但它的思路是对的：定时采集 → 计算指标 → 输出结果。后面几章，我会带你一步步把它升级成一个完整的实时检测 SDK。

好了，这一章就到这里。记住一句话：没有实时检测的系统，就像蒙着眼睛开车。你觉得自己开得挺稳，其实前面就是悬崖。