一、CPU性能指标：系统运算能力的核心

1. CPU使用率（Usage%）

CPU使用率反映处理器在特定时间内的负载情况，通常分为用户态（user）、内核态（system）、空闲（idle）等细分指标。高用户态使用率可能表明应用计算密集，而高内核态占比则需警惕系统调用或中断处理异常。
监控工具：top、htop、vmstat 1（每秒刷新）

# 使用vmstat查看CPU上下文切换次数（cs列）和中断次数（in列）
vmstat 1

优化建议：通过perf top定位热点函数，优化算法或升级CPU核心数。

2. 上下文切换（Context Switches）

上下文切换指CPU在不同进程/线程间切换的次数，过高会导致性能下降。正常值应低于10万次/秒，若超过需检查是否因锁竞争或调度策略不当引发。
诊断命令：

# 查看进程级上下文切换
pidstat -wt 1

3. 运行队列长度（Run Queue）

通过vmstat的r列观察等待CPU资源的进程数。若持续超过CPU核心数×2，表明系统过载。
解决方案：增加CPU资源或优化进程优先级（nice值）。

二、内存性能指标：避免OOM的关键

1. 内存使用率（Memory Usage）

需区分物理内存（Mem）和交换分区（Swap）的使用情况。高Swap使用率可能引发性能抖动，理想状态下Swap使用率应接近0。
监控命令：

free -h  # 以易读格式显示内存
cat /proc/meminfo | grep -E "MemTotal|MemFree|SwapTotal|SwapFree"

2. 缓存与缓冲区（Cache/Buffer）

Linux利用空闲内存缓存文件数据（Cache）和块设备元数据（Buffer）。释放缓存可通过：

sync; echo 3 > /proc/sys/vm/drop_caches  # 谨慎操作，生产环境慎用

调优建议：调整vm.swappiness（默认60）降低Swap使用倾向。

3. 内存泄漏检测

使用valgrind --tool=memcheck分析应用内存分配，或通过dmesg | grep -i "out of memory"检查OOM Killer日志。

三、磁盘I/O性能指标：存储瓶颈的根源

1. IOPS与吞吐量（Throughput）

• 随机IOPS：SSD可达数万，HDD仅数百
• 顺序吞吐量：千兆网卡理论极限约125MB/s
  测试工具：

  fio --name=randread --ioengine=libaio --iodepth=32 --rw=randread \
    --bs=4k --direct=1 --size=1G --numjobs=4 --runtime=60 --group_reporting

2. 磁盘利用率（Utilization）

通过iostat -x 1的%util列观察磁盘繁忙程度。若持续接近100%，需优化I/O模式或升级存储设备。
案例分析：某数据库服务器因%util达95%，改用RAID10后性能提升3倍。

3. 等待队列（Await）

iostat的await列表示I/O请求的平均等待时间（ms）。超过50ms需警惕存储延迟问题。

四、网络性能指标：保障数据传输效率

1. 带宽利用率（Bandwidth Utilization）

使用ifstat 1或nload监控网卡实时流量。满载时可能引发丢包或延迟。
QoS策略：通过tc命令限制带宽：

tc qdisc add dev eth0 root handle 1: htb default 12
tc class add dev eth0 parent 1: classid 1:12 htb rate 10mbit

2. 连接数与状态（Connections）

netstat -anp | awk '/tcp/ {print $6}' | sort | uniq -c  # 统计连接状态
ss -s  # 更高效的替代命令

异常处理：若TIME_WAIT连接过多，可调整net.ipv4.tcp_tw_reuse=1。

3. 丢包与重传（Packet Loss/Retrans）

通过sar -n TCP,ETCP 1观察TCP重传率。超过1%可能需检查网络设备或MTU设置。

五、综合监控工具推荐

1. Prometheus + Grafana：可视化监控方案，支持自定义告警
2. Percona PMM：数据库专项监控，集成QPS、锁等待等指标
3. Sysstat套件：包含sar、iostat、pidstat等经典工具

六、性能调优实战案例

场景：某Web服务器响应变慢，top显示CPU等待I/O（%wa）达40%。
诊断步骤：

1. iostat -x 1确认磁盘%util接近100%
2. lsof | grep deleted发现删除文件未释放空间（因进程持有）
3. 重启相关服务后，%wa降至5%，TPS恢复至正常水平。

七、总结与建议

1. 建立基线：通过sar -u 1 3600 > cpu_baseline.log收集历史数据
2. 分层监控：从主机到容器，从硬件到应用层逐级排查
3. 自动化告警：设置阈值（如CPU>85%持续5分钟）触发通知

附：关键指标速查表
| 指标类别 | 关键参数 | 正常范围 |
|————————|—————————————-|—————————-|
| CPU | %user, %system, %wait | <70%, <30%, <20% |
| 内存 | MemFree, SwapUsed | SwapUsed≈0 |
| 磁盘I/O | %util, await | <80%, <50ms |
| 网络 | rx/tx kB/s, retrans | <带宽80%, <1% |

通过系统性监控这些指标，运维人员可快速定位性能瓶颈，实现Linux服务器的高效稳定运行。