CPU和内存监控指标分别看什么，一句话概括：CPU重点看使用率、负载和上下文切换，内存重点看使用量、可用量和Swap换页情况，两者配合才能判断系统瓶颈究竟在哪。
CPU监控指标怎么看
CPU监控的核心不是看一个数字，而是看它背后暴露的系统行为，很多人只会盯着“使用率”这一个数值，遇到告警就重启,其实大部分时候瓶颈在别的指标上。
使用率不是越高越糟糕
Linux里top命令第一行有个%Cpu(s)，这串数字代表的是整体占用，但你需要先分清这几种状态：us是用户态，sy是内核态，wa是等待I/O，id是空闲，如果wa占比高，问题往往不在CPU本身，而是磁盘太慢，比如你跑了个数据清洗脚本，CPU使用率只有30%，但wa到了50%，这时候加CPU核数没有任何意义,该换SSD或者优化SQL才对。
行业内比较常见的判断口径是：使用率长时间超过85%才视为繁忙，偶尔冲到90%再掉下来不算故障，如果是云服务器，还要区分是“计算密集”还是“请求突发”，计算密集比如视频转码，持续高使用率是正常预期；请求突发比如抢购秒杀，使用率瞬间拉满但秒级回落,也不构成风险。
负载（Load Average）才是真正的“排队长度”
uptime命令会输出三个数字，比如load average: 4.21, 3.80, 3.65，这三个数分别是1分钟、5分钟、15分钟的平均负载，负载的含义是“正在运行和等待运行的进程数”,不是百分比。
判断负载是否过高的经验公式是把负载除以CPU核心数。nproc命令能看核心数，如果结果是4核机器负载跑到4.0以下，算正常；一旦超过核心数，就意味着有进程在排队等着被调度，这时候用户会感觉卡顿，但CPU使用率可能只有60%,所以负载比使用率更能代表用户的真实体验。
上下文切换过高时，CPU在“空转”
vmstat 1可以观察cs列，这就是每秒上下文切换次数，数值持续在几万甚至十几万时，说明系统有一堆线程在疯狂抢占CPU调度时间片，常见触发原因是高并发短连接，比如Nginx收到大量握手请求，或者Java应用里线程池开得太多，这时候你看到的CPU使用率不高，但服务响应变慢，业内专家指出这种情况优先检查锁竞争和线程池配置,而不是盲目扩容。
每个核心单独追踪才有意义
top进入后按1，可以看到每个CPU核心的使用率，多核场景下一个核心跑到100%，其他核心在摸鱼，这种情况普遍出现在单线程应用里，比如Redis的某些持久化场景、老旧的PHP脚本，只看整体平均值会掩盖这种失衡,排查时一定要按核心逐一确认。
内存监控指标到底该盯哪些
内存比CPU更容易让人误判，因为Linux对内存的管理策略和Windows完全是两套逻辑，你看到“已用90%”不一定是危险信号。
不要被Used吓到，看Available
free -h命令的输出里，used列只是表示被进程持有的内存，但这不代表快满了，Linux会把空闲内存拿去做Cache（缓存文件读取），这部分是会被自动回收的，所以真正该关注的是available列，它估算的是“在不触发Swap的前提下还能分配多少内存”。
有次帮朋友排查一个数据库服务器，他紧张地说内存用了97%，结果available还有8GB，原因是InnoDB的缓冲池把磁盘数据都预读进了Cache，这时候used高但available充足，系统不会变慢,反而因为缓存命中率高而飞快。
Swap不是用来“不够了才用”的
free -h里Swap一栏如果si和so（swap in/out）持续非零，才是真正该拉响的警报。vmstat 1能看到si和so两列,满足下面任意一条就要处理：
si持续大于0，说明物理内存不够，系统正在把页从Swap分区换回内存,这是极慢的。so持续大于0，说明内存压力大，内核在把页面写到磁盘,同样慢。
Swap换页的典型代价是应用延迟从毫秒级飙升到秒级，因为你本来应该是读写内存，现在变成了等磁盘，别指望加Swap能根治内存不足，它只能兜底防OOM Killer乱杀进程。
内存抖动比单纯占满更值得警惕
如果free -h每隔一两秒看一次，available数值上下跳动幅度超过1GB，这就叫内存抖动，常见于JVM堆内存频繁GC，或者Node.js应用有内存泄漏，这时候单纯看总量没意义，得用pidstat -r 1按进程追踪RSS变化。
每个进程的驻留内存（RSS）怎么拆
top里RES列是进程实际占用的物理内存，不过有个坑，多个进程共享的库不会重复计算，所以把所有进程的RES相加会超过总内存数，排查内存问题时，用
ps aux --sort=-%mem按内存倒序排列，前十个进程基本就是吃内存的大户。
Windows平台下的监控差异
Windows没有Load Average这种概念，任务管理器里的“内存”百分比和Linux同样存在Cache混淆的问题，更准确的做法是打开“资源监视器”，重点看“为硬件保留的内存”和“已修改”这两项。“为硬件保留”如果超过1GB，多半是显卡驱动或主板固件吃掉了内存。“已修改”数值持续增大表示有进程频繁写文件但不落盘,这里经常藏着性能隐患。
Windows自带的perfmon.msc性能监视器也可以添加计数器，但日常排查用默认的任务管理器加资源监视器就足够应付大多数场景了，如果是Windows Server，更建议直接看Get-Counter的PowerShell命令,能拿到可编程的指标快照。
工具选择：都是套路，不用全装
不同环境选顺手的工具就行,不必追求全家桶。
Linux命令行三板斧
top/htop：交互式查看CPU和内存实时状态，htop按F6能按某列排序，比top直观。vmstat 1 10：每1秒输出一次共10次，重点看r（运行队列）、cs（上下文切换）、si/so（换页）。dstat（可能需安装）：组合展示CPU、内存、磁盘I/O和网络,一眼看出瓶颈关联。
云厂商控制台的延迟陷阱
简米云或酷番云的监控面板默认1分钟粒度，对CPU短时飙高根本拍不到，要看到秒级数据，要么付费开通较细粒度的监控，要么自己在服务器上装Prometheus + node_exporter，node_exporter默认抓取间隔是15秒,能捕捉到大多数瞬时尖峰。
告警阈值别照搬模板
不少团队的告警规则是CPU>80%就报警，结果天天半夜被吵醒，更合理的做法是设置连续N分钟超过阈值再触发，比如连续5分钟CPU超过90%，避免正常负载波动的干扰，内存可用量低于总内存的10%且Swap持续增长,这个组合条件的告警才真正值得看。
一个实际排查案例的完整思路
假设一台云服务器最近每天下午响应慢,你能用它该这样定位到底看哪些指标：
- 用
uptime看负载，假设负载是16，核数是8，说明排队的进程堵了两倍
。
- 用
vmstat 1看cs（上下文切换），如果切换次数忽然飙高，结合CPU使用率不高,说明可能是锁竞争或网络中断风暴。 - 用
free -h看available，确认物理内存是否被耗尽，以及Swap的si是不是在涨。 - 用
pidstat -r 1或top按RSS排序，找到具体是哪个进程在消耗，如果是Java应用，还得继续用它自带的jstat看GC频率,才能区分到底是堆内存太小还是代码泄漏。
常见的两个误区，别踩
CPU高就加CPU
不一定，如果是wa（I/O等待）高导致的CPU高，加CPU解决不了磁盘慢的根源，性能损耗在等磁盘,CPU只是在空转等指令。
内存多开点就没事
如果应用本身有内存泄漏，给它16GB会占满16GB，给它32GB也会占满32GB，行业共识认为加内存只能拖延问题爆发的时间，排查泄漏点才是正路，记得定期用ps -eo pid,rss,cmd --sort=-rss对比进程RSS的增量。
Q&A：关于CPU和内存监控指标分别看哪些数据
问：Windows和Linux下CPU和内存监控指标分别看哪些数据,核心差别大吗？
答：核心看的东西一样，都是使用率、负载/可运行队列、交换分区使用情况，差别在于命令和工具，Windows更依赖任务管理器和资源监视器，Linux用top和vmstat，Linux下的available概念比Windows的“可用内存”更精确，Windows里被缓存的内存也计入“已用”,容易造成误判。
问：服务器CPU和内存监控指标怎么看才能防止半夜睡不好？
答：别只设置过高阈值，要组合条件判断，建议至少看三个指标的联动：CPU使用率连续超过90%持续5分钟、负载超过核心数、Swap持续换页，同时打开云监控的历史趋势图，对比业务高峰时段和告警时段的差异，确认是规律性波动还是突发异常，前者你大可放心睡，后者是代码或者流量问题,优化思路完全不同。
问：Linux查看CPU和内存监控指标命令记不住,只学会哪两个就够用？
答：先记住top和free -h。top按1看核心负载，按P按CPU排序，按M按内存排序；free -h看内存总量、可用量和Swap，这两个命令覆盖95%的日常排查场景,其他命令在遇到深层问题再看手册也不迟。