跳转至

监控服务器

📌 指标分析

🚁 CPU/系统平均负载

系统平均负载，CPU在一段时间内的使用量。

一般来说，系统平均负载超过CPU核数数倍时，视为异常。

🔧 top-实时监控系统性能

  • top -u user # -u指定用户启动的进程
  • top -H -p pid # -u -p不能一起用，-H启用线程模式，显示进程中各线程的详细信息。

交互按键:

  • 数字键1，切换显示每个CPU核心的使用情况。
  • P，按CPU使用率排序
  • M，按内存使用量排序
  • u -> 输入用户名 -> 回车，查看某个用户的进程
  • k -> 输入pid，杀进程
  • R，反转当前排序。
  • Z，切换颜色模式。

每个CPU核心使用情况:

  • us - user 用户使用量
  • sy - system 系统使用量
  • id - idle 空闲使用量
  • wa - wait io等待使用量

load average - 平均负载，有3个数值，分别代表1、5、15分钟内的平均负载。

若数值递减，说明系统压力逐渐增大。若值大于等于CPU核数，说明超负荷。

🔧 pidstat -d

除了看cpu使用量，还需要看等待（非IO等待）；当超负荷运行时，等待/阻塞的进程就明显较多。

pidstat看用户进程的CPU占用，其中%wait代表进程等待，包括IO等待、锁竞争等待、资源等待、同步等待。

若怀疑是IO等待，需结合iostat等工具进一步确认。

场景分析:

  • 当CPU使用率高，平均负载低（(使用+等待)/核数），说明当前进程正在使用占多数，等待的少，此时找cpu占用高的进程进行分析（如java应用、db、redis等）。
  • 当CPU使用率低，平均负载高，说明当前进程正在等待占多数。等待需要区分计算密集型、IO密集型。
  • 当两者都高，说明使用、等待的进程都多，也是找cpu占用高的进程进行分析。

🚁 内存

free -h
查看内存使用情况

🔧 swap

交互区，当机器内存不足时会使用，且性能会下降。一般都禁用swap区。

vmstat 1 5
si - swap in，从swap区读到内存
so - swap out，从内存写到swap区

🚁 网络

宽带: 如100兆，即100mbps或100m bit/s

带宽: 上述宽带换算为带宽，即100Mbps / 8 = 12.5MB/s

常用命令包括:

  • lsof -n 或者 netstat -tpln，查端口占用。
  • telnet ip port 或者 ping，测试网络能否调通。
  • ifconfig-查内网ip；curl cip.cc-查公网ip。
  • iperf，测试最大TCP、UDP带宽性能；需要服务端（iperf -s）和客户端（iperf -c ip -t 20）。
  • tcping -t 10 ip 80，看目标机器端口是否开放。

🔧 性能测试如何考虑网络

  • 公司内网/局域网
  • 服务器不在公司内部，在客户机器或者其他公司的局域网；通过跳板机/堡垒机压测
  • 项目部署在云服务器；在云服务器申请测试机，保证在同个局域网下

📌 加压工具

# 前俩是否必须待确认
#sudo yum install -y epel-release
#sudo yun install -y sysstat
# 使用yum能自动安装依赖
sudo yum install -y stress

# 模拟8个进程加压
stress -c 8 --timeout 600

# 模拟IO压力，单个进程不断执行sync（内存映射到磁盘）
stress -i 1 --timeout 600

📌 面试题

🚁 如果性能测试需要在云环境中执行，您会如何设计测试以适应云服务的弹性和可扩展性？

  1. 在云服务器申请测试机，保证在同个局域网下。
  2. 使用JMeter主从模式进行压测，监控常规的性能指标（如TPS、响应时间、错误率等）。
  3. 观察系统是否会自动扩容: 设计阶梯式加压，在压力上升时，是否触发了自动扩容策略，扩容的速度是否满足需求。
  4. 观察容器负载是否均衡: 使用监控面板查看各节点的QPS、CPU、内存使用情况，是否出现资源倾斜。
  5. 压力释放后系统的恢复能力: 压力结束后，系统是否能够自动缩容，系统资源是否及时释放，缩容时是否出现请求异常。
  6. 业务逻辑验证: 脚本添加断言，检查自动扩缩容时，数据一致性是否得到保障。

🚁 CPU占用高，其他资源（内存、IO）不高，原因及分析

CPU高但其他资源无瓶颈，说明系统瓶颈在“计算密集型任务”，常见原因包括：

  • 无限循环/递归
  • 复杂计算：大量数学运算（如加密/解密、哈希计算）、大数据量循环处理（如遍历百万级集合）。
  • 频繁GC
  • 线程竞争：多线程争夺锁，导致上下文切换频繁。
  • 第三方库/框架问题：某些第三方组件（如日志框架、序列化工具）的低效实现（如频繁字符串拼接）。

分析步骤

  1. top -p <pid>聚焦指定进程，找CPU占用高的进程。
  2. top -H -p <pid>显示进程内线程，找到CPU占用高的线程。
  3. 使用Arthas的trace命令，定位到具体方法。
  4. 验证GC情况：jstat -gc <pid> 1000每1秒输出GC统计；FGC-Full GC次数、FGCT-Full GC时间，计算是否频繁（如每分钟多次FGC）。

🚁 CPU 200%，是否存在问题？

当双核CPU负载200%，意味着两个核心满负荷运行，若应用是多线程/并行计算（如Java线程池处理大量请求），且TPS稳定、响应时间正常，则是合理的（充分利用多核资源）。

但TPS未随着CPU负载而增加，且响应时间异常长，则存在问题：

  • 线程竞争剧烈，大量线程争夺同一锁，导致上下文切换频繁
    vmstat 1看上下文切换次数（cs指标）：若cs远高于正常水平（如>10000次/秒），说明线程竞争剧烈。

  • 频繁GC占用CPU
    jstat -gc <pid> 1000每1秒输出GC统计
    FGC-Full GC次数、FGCT-Full GC时间，计算是否频繁（如每分钟多次FGC）