系统性能的“晴雨表”：CPU与内存使用率
服务器跑得慢，第一个该看的就是CPU和内存。就像家里的电表水表，这些基础指标能直接反映系统负荷。CPU持续高于80%，可能意味着计算资源吃紧，某些进程在“霸占”处理时间。内存使用过高，甚至频繁触发交换（swap），应用响应就会变卡，特别是Java这类吃内存的服务。
比如你发现网页打开越来越慢，登录服务器一看，CPU用了95%，基本就能断定是计算瓶颈。这时候再查具体是哪个进程在作怪，效率更高。
磁盘I/O：别让存储拖后腿
数据库查询突然变慢，不一定程序有问题，可能是磁盘扛不住了。监控磁盘的读写延迟、IOPS（每秒输入输出次数）和吞吐量很关键。尤其是机械硬盘，随机读写能力差，一旦并发高起来，队列堆积，响应时间直线上升。
像MySQL这类依赖磁盘持久化的服务，如果发现写入延迟飙升，配合iostat查看await、%util等指标，很容易定位到是不是磁盘成了瓶颈。
网络流量与连接数
网站打不开，也可能是网络被打满了。监控网卡的接收和发送带宽，避免达到物理上限。同时关注TCP连接数，特别是处于TIME_WAIT或CLOSE_WAIT状态的连接数量。过多的短连接可能导致端口耗尽，而大量CLOSE_WAIT则暗示应用没正确关闭连接。
举个例子，API接口突然超时，排查发现服务器的ESTABLISHED连接接近65535上限，那问题很可能出在连接池配置或客户端调用方式上。
JVM调优要看的几个重点
Java应用特别依赖JVM状态监控。GC频率和停顿时间是最核心的指标。频繁的Full GC会导致服务“卡死”几秒，用户明显感知到卡顿。通过jstat或Prometheus抓取Young GC、Full GC的次数和耗时，配合堆内存使用曲线，能判断是否需要调整堆大小或更换垃圾回收器。
比如观察到每小时一次Full GC，且每次停顿超过1秒，就该考虑是不是老年代空间不足或者存在内存泄漏。
数据库响应与慢查询
应用慢，八成问题出在数据库。监控SQL平均响应时间、QPS（每秒查询数）、慢查询数量必不可少。开启慢查询日志，记录执行超过阈值的语句，是优化的第一步。
某次上线后订单页加载变慢，查监控发现某个JOIN查询耗时从20ms涨到800ms，定位到缺少索引，加完立马恢复正常。
应用层指标：响应时间与错误率
最终用户体验体现在接口响应时间和成功率上。通过APM工具（如SkyWalking、Pinpoint）采集每个接口的P95、P99响应时间，以及HTTP 5xx、4xx错误率，能快速发现异常波动。
比如某个微服务突然P99上升到2秒，而其他服务正常，结合日志很容易锁定问题范围。
代码示例：简单采集CPU使用率
Linux下可以通过/proc/stat获取CPU基本信息，下面是一个简易解析脚本：
cat /proc/stat | grep '^cpu '
<!-- 输出类似 -->
cpu 12345 678 91011 123456 789 0 1234 0 0 0
前四个数字分别是user、nice、system、idle的时间片，通过前后两次采样计算idle占比，就能得出CPU使用率。