一、CPU性能指标与监控方法

1.1 核心监控指标

CPU使用率是评估服务器计算能力的首要指标，需关注以下细分维度：

• 用户态/内核态占比：通过top或vmstat命令查看us（用户进程）和sy（系统内核）占比，理想状态下us应高于70%，若sy持续超过30%可能存在内核态性能瓶颈。
• 上下文切换次数：每秒上下文切换（cs列）超过10万次可能引发性能下降，可通过vmstat 1实时监控。
• 运行队列长度：sar -q 1 3命令输出的runq-sz值超过CPU核心数2倍时，表明进程等待严重。

1.2 监控工具实践

• mpstat：mpstat -P ALL 1可分析各物理核心的负载均衡情况，定位单核过热问题。
• perf工具：通过perf stat -e cache-misses,branch-misses统计缓存命中率和分支预测失败率，优化算法设计。
• 动态追踪：使用bpftrace编写脚本追踪特定函数调用耗时，示例：

  #!/usr/bin/bpftrace
  uprobe:/lib/x86_64-linux-gnu/libc.so.6:malloc {
    @start[pid] = nsecs;
  }
  uretprobe:/lib/x86_64-linux-gnu/libc.so.6:malloc /@start[pid]/ {
    @duration = hist(nsecs - @start[pid]);
    delete(@start[pid]);
  }

二、内存管理关键指标

2.1 内存使用分析

• 可用内存计算：实际可用内存=free + buffers + cached（需排除Slab内存），可通过free -h快速查看。
• Swap活动监控：sar -S 1观察pswpin/pswpout值，若Swap使用率超过10%需警惕内存泄漏。
• 大页内存配置：对于数据库类应用，启用透明大页（THP）可能导致性能波动，建议通过echo never > /sys/kernel/mm/transparent_hugepage/enabled禁用。

2.2 内存优化策略

• OOM Killer调优：修改/etc/sysctl.conf中的vm.panic_on_oom=1避免关键进程被误杀。
• NUMA架构优化：多路CPU场景下，使用numactl --preferred=0绑定进程到特定NUMA节点。
• 内存碎片整理：对于长时间运行的服务器，定期执行echo 1 > /sys/kernel/mm/compact_memory。

三、磁盘I/O性能深度解析

3.1 存储设备监控

• IOPS与吞吐量：iostat -x 1中的r/s（读IOPS）、w/s（写IOPS）、rkB/s（读吞吐）需结合设备规格评估。
• 延迟分析：await值超过10ms可能存在队列堆积，svctm接近await表明设备饱和。
• SSD寿命监控：通过smartctl -a /dev/sda查看Percentage_Used和Media_Wearout_Indicator。

3.2 性能优化方案

• 文件系统选择：数据库场景优先选用XFS，小文件密集型应用考虑ZFS。
• I/O调度器调优：SSD设备建议设置为deadline或noop，通过echo deadline > /sys/block/sda/queue/scheduler修改。
• RAID配置建议：RAID10适合高随机I/O场景，RAID5/6需谨慎用于写密集型负载。

四、网络性能监控体系

4.1 关键网络指标

• 带宽利用率：sar -n DEV 1中的rxkB/s和txkB/s需与网卡物理带宽对比。
• 连接状态统计：netstat -s查看listen dropped和timeout次数，排查连接堆积问题。
• TCP重传率：ss -i输出的retrans值超过1%需检查网络质量。

4.2 网络调优实践

• 内核参数优化：

  # 增大TCP缓冲区
  net.core.rmem_max = 16777216
  net.core.wmem_max = 16777216
  # 启用TCP快速打开
  net.ipv4.tcp_fastopen = 3

• QoS配置示例：使用tc命令限制特定IP的带宽：

  tc qdisc add dev eth0 root handle 1: htb default 12
  tc class add dev eth0 parent 1: classid 1:12 htb rate 10mbit
  tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.1.100 action mirred egress redirect dev ifb0

五、系统级综合监控

5.1 进程级监控

• 进程资源占用：pidstat -t -p <PID> 1分析线程级CPU/内存使用。
• 僵尸进程处理：定期执行ps aux | grep 'Z'查找僵尸进程，通过kill -9 <PPID>终止父进程。

5.2 系统日志分析

• dmesg警告处理：重点关注I/O error、OOM和Segmentation fault日志。
• 审计日志配置：通过auditd监控敏感文件访问，示例规则：

  -w /etc/passwd -p wa -k passwd_changes
  -w /etc/shadow -p wa -k shadow_changes

六、性能基准测试方法

6.1 标准化测试工具

• CPU测试：sysbench cpu --threads=4 run
• 内存测试：stress-ng --vm 2 --vm-bytes 1G --timeout 60s
• 磁盘测试：fio --name=randwrite --ioengine=libaio --rw=randwrite --bs=4k --numjobs=1 --size=1G --runtime=60 --time_based --end_fsync=1 --filename=/tmp/testfile

6.2 测试结果解读

• 95%延迟值：在数据库性能测试中，95%延迟比平均值更能反映用户体验。
• 性能衰减曲线：连续多次运行测试，观察性能是否稳定下降，判断是否存在资源泄漏。

七、自动化监控方案

7.1 Prometheus配置示例

# prometheus.yml配置片段
scrape_configs:
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['localhost:9100']
    metric_relabel_configs:
      - source_labels: [__name__]
        regex: 'node_cpu_seconds_total'
        target_label: 'cpu_mode'
        replacement: '$1'

7.2 告警规则设计

# alert.rules.yml示例
groups:
- name: cpu.rules
  rules:
  - alert: HighCPUUsage
    expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
    for: 10m
    labels:
      severity: critical
    annotations:
      summary: "High CPU usage on {{ $labels.instance }}"
      description: "CPU usage is above 90% for more than 10 minutes."

本文系统梳理了Linux服务器性能监控的五大维度，结合具体工具使用和配置示例，提供了从指标采集到问题定位的完整方法论。实际运维中，建议建立分层次的监控体系：基础指标（CPU/内存/磁盘）每分钟采集，业务指标（QPS/延迟）每秒采集，异常指标实时告警。通过持续的性能基线建设，可提前发现60%以上的潜在性能问题。