CPU和内存监控的核心指标不能只看使用率，CPU要看平均负载、运行队列和温度，内存要看实际可用量、交换使用和缓存命中率。很多人盯着任务管理器里的百分比，却在系统卡顿的时候找不到根因，因为指标选错了。
CPU监控指标到底看哪些？
CPU使用率是大家最熟悉的指标,但单看它远远不够，一个CPU满载但任务队列很短的系统，和一个CPU使用率只有50%但队列拥堵的系统，后者的体验可能更差，所以需要把使用率、负载、温度、上下文切换组合起来看。
CPU使用率：用户态、系统态和等待I/O
使用top或htop命令，你会看到us、sy、id、wa、st这几项。us（用户态） 是应用程序占用，sy（系统态） 是内核占用，wa（等待I/O） 是CPU在等磁盘或网络，st（偷取时间） 只在虚拟化环境下出现，表示宿主机抢走了你的CPU时间片。
- 如果us持续高于85%，说明应用程序在全力计算，可能需要优化代码或扩容。
- 如果sy偏高（超过15%），考虑是否频繁调用系统调用，或者内核本身有瓶颈。
- 如果wa直接吃掉20%以上，大概率是磁盘或网络I/O拖后腿，加CPU没用。
- 如果是云服务器,st超过10%意味着邻居在争抢资源，该换实例规格了。
行业共识认为，CPU使用率的长期预警线应该设在70%，而不是90%，因为接近满载时，任务队列会迅速堆积，响应时间指数级上升。
平均负载与运行队列：真正反映压力的指标
使用uptime或cat /proc/loadavg可以看到三个数字（1分钟、5分钟、15分钟平均负载）。平均负载不是百分比，它是排队等待CPU的任务数，判断依据很简单：如果负载值持续大于CPU核心数，说明有任务在排队。
- 举例：4核CPU，负载长期在6以上，意味着平均有2个任务在等待，系统已经过载。
- 运行队列长度（
vmstat 1第一列r值）更重要，如果r值长期大于CPU核心数，即使使用率看起来不高，实际也卡。
CPU温度与降频：硬件排查的起点
物理服务器或笔记本,CPU温度过高会触发降频，性能直接打折扣，使用sensors命令或者turbostat可以查看当前温度和频率，如果频率远低于标称主频，同时温度接近90°C，赶紧除尘或检查散热。降频后的CPU，使用率再低也没用。
内存监控指标看哪些数据？
内存的使用率同样容易误导人,Linux系统会把空闲内存拿来当缓存，而Windows的已用内存也包含大量可回收部分，你以为内存不够，其实只是算法没看懂。
内存使用率与交换分区：什么算“异常”
free -h命令输出中，available列才是应用程序实际可用的内存，而不是used列，很多人看到used 80%就紧张，但available可能还有50%，因为buff/cache随时可以释放。
- swap使用率是红线,如果swap used持续非零且增长，说明物理内存真的不够了，系统在用磁盘当内存，速度会慢到崩溃。
- 对于数据库这类吃内存的应用,内存命中率比使用率重要，比如MySQL的Buffer Pool命中率如果低于99%，就该加内存了。
缓存与缓冲区：该不该被计入已用内存
Linux里buff/cache是磁盘和文件系统的缓存，在内核需要时可以立刻回收，所以监控内存时，别把buff/cache算作“已用”，业内专家指出，很多运维报警就是因为没有区分used和available，导致误判。
- 具体看法：
free -m输出中的available列是直接可用的内存量，如果available持续低于总内存的10%，就算used只有70%，也说明内存紧张。 - 使用
top按内存排序（按M键），查看进程的RES（常驻内存）和VIRT（虚拟内存），如果某个进程的RES持续增长直到OOM被kill，这就是典型的内存泄漏信号。
内存泄漏的排查：RSS与虚拟内存
用top -o %MEM持续观察，如果一个进程的RES在一周内逐小时上升，且没有回落，大概率存在内存泄漏，确认后用pmap -x <PID>查看具体内存段，或者用valgrind --leak-check=full定位代码，小提示：容器环境中，cgroup的内存限制会触发OOM，但看不出来是哪个进程在吃，所以宿主机的/var/log/kern.log里的OOM killer日志是排查关键。
场景化监控：CPU和内存指标在不同负载下的权重
不同业务对CPU和内存的敏感度完全不同,一套监控模版走天下容易误判。
数据库服务器：内存命中率比CPU使用率更关键
数据库（MySQL、PostgreSQL）的瓶颈大多在内存和磁盘I/O，CPU使用率虽然也要看，但更重要的是内存缓存命中率和swap使用率，如果命中率下降，查询会大量落到磁盘，CPU也会因为等待I/O而飙高，这时加CPU不如加内存。
- 监控指标侧重：可用内存、缓存命中率、swap in/out（
vmstat的si/so）、CPU iowait。
Web服务器：CPU平均负载与并发连接数
Nginx或Apache这类Web服务,CPU负载和连接数直接相关，当并发连接数上升，CPU上下文切换（vmstat的cs列）会暴涨，如果cs每秒超过几十万，说明系统在频繁切换进程，性能会下降，此时关注平均负载和上下文切换，比单纯看CPU使用率更准。
- 监控指标侧重：平均负载、运行队列长度、上下文切换速率、CPU idle中的wait。
云服务器与容器环境：监控指标的“虚”与“实”
云服务器里的CPU使用率可能是宿主机资源的“分时复用”，st值（steal time）是宿主机抢走CPU的时间，如果st超过10%，说明你的物理邻居在争资源，该考虑换物理机或升级实例，容器环境下，内存限制由cgroup控制，但free看到的是宿主机的内存，需要用cat /sys/fs/cgroup/memory/memory.usage_in_bytes查看容器真实使用量。
Q&A：CPU和内存监控常见问题
CPU使用率总是100%，但系统不卡，需要关注吗？
如果CPU使用率100%但平均负载小于核心数，说明任务恰好填满了CPU没有排队，比如视频转码或者科学计算，此时系统效率高，不卡是正常的，但需要关注温度，长期满载可能导致降频甚至硬件损坏，如果负载同时超过核心数，说明已经超载，必须处理。
内存占用率过高怎么解决？需要加内存吗？
先看available列是否充足，如果available够用，只是used和buff/cache高，说明系统在正常使用缓存，无需加内存，如果available低于总内存的10%且swap持续增长，说明物理内存不足，解决方案：先排查内存泄漏应用，用`top`按RES排序找出异常进程，如果确认是正常业务需要，再考虑扩容，注意，搬瓦工等低价VPS常出现swap挤占问题，加内存前先确认实例是否超售。
Linux 下查看CPU和内存的常用命令组合
`top`（实时概览，按1看每核，按M按内存排序）、`vmstat 1`（每1秒输出CPU、内存、I/O、上下文切换）、`free -h`（内存总量与可用量）、`htop`（交互式，带颜色和行列排序）、`sensors`（CPU温度），推荐组合：`watch -n 1 'vmstat 1 3 | tail -1'` 持续监控CPU和内存变化。
CPU和内存监控不是看单一数字,而是看使用率、负载、队列、缓存、温度之间的关联，把指标和业务场景对应起来，才能避免被百分比的表象迷惑。