当前位置:首页>Linux>Linux系统监控实战:top/htop/sar/perf性能分析

Linux系统监控实战:top/htop/sar/perf性能分析

  • 2026-10-11 07:55:56
Linux系统监控实战:top/htop/sar/perf性能分析

一、场景引入

周五下午,监控系统突然告警:线上Java服务CPU使用率从15%飙升至95%,响应时间从50ms暴涨到800ms,用户投诉电话打爆了客服。你紧急登录服务器,面对黑底白字的命令行,手心冒汗——这该怎么办?

这就是系统监控能力的价值所在。在生产环境中,性能问题随时可能发生:CPU高企、内存泄漏、磁盘IO瓶颈、网络拥塞……如果不懂监控工具,就像盲人摸象,只能靠重启服务器碰运气。

二、核心知识点详解

知识点1:top命令——系统监控的"听诊器"

【概念】top是Linux系统自带的实时进程监控工具,类似于Windows的任务管理器。它能动态显示系统负载、CPU/内存使用情况,以及各进程的资源占用情况。

【原理】top通过读取/proc文件系统(如/proc/stat、/proc/meminfo、/proc/[pid]/stat)获取系统运行数据,每隔一定时间(默认3秒或5秒)刷新一次。

# 基础用法top                  # 启动top,默认3秒刷新top -c               # 显示完整命令行top -p 1234,5678     # 只监控指定进程top -H               # 显示线程(排查多线程程序)top -b -n 1 > top.log # 批处理模式,输出一次后退出# 交互快捷键(运行时按)# P - 按CPU使用率排序(默认)# M - 按内存使用率排序# T - 按运行时间排序# 1 - 展开显示各CPU核心# k - 杀死进程(输入PID和信号)# q - 退出

【应用】

  • 快速定位CPU高占用进程:按P排序,找到%CPU最高的进程

  • 排查内存泄漏:按M排序,观察进程内存是否持续增长

  • 负载异常诊断:load average持续高企,说明系统过载或IO瓶颈

【踩坑】

  • 坑1:误读负载均值:单核服务器load average: 2.0表示严重过载,但8核服务器这是正常值。判断标准:负载 / CPU核心数,>1需关注,>2需警惕

  • 坑2:忽视僵尸进程:zombie计数>0时,需找到父进程并处理

知识点2:sar命令——系统性能的"黑匣子"

【概念】sar(System Activity Reporter)能收集、报告、保存系统活动信息。最大的优势是历史数据回溯——即使问题发生在昨晚,今天也能查看当时的性能数据。

【原理】sar依赖后台守护进程sadc,默认每10分钟采集一次系统指标,保存到/var/log/sysstat/saXX(XX为日期)。

# 安装并启用sudo apt install sysstat -ysudo sed -i 's/ENABLED="false"/ENABLED="true"/' /etc/default/sysstatsudo systemctl restart sysstat# 常用命令sar -u          # 查看今天CPU使用历史sar -u 1 5      # 实时监控,每1秒采样,共5次sar -r          # 内存使用历史sar -d          # 磁盘活动历史sar -n DEV      # 网络流量历史# 查看特定日期的数据sar -u -f /var/log/sysstat/sa09  # 查看9号的CPU数据

【踩坑】

  • 坑1:数据被覆盖:默认只保存7天,修改/etc/sysstat/sysstat的HISTORY=28可保存28天

  • 坑2:采集间隔太长:默认10分钟采集一次,如果故障持续时间<10分钟,可能捕捉不到峰值

知识点3:perf命令——内核级性能剖析神器

【概念】perf是Linux内核自带的性能分析工具,基于硬件性能监控单元(PMU)和内核跟踪点,能以极低的开销(<5%)对运行中的程序进行采样,生成火焰图,定位热点函数。

# 安装sudo apt install linux-tools-common linux-tools-generic -y# 常用命令sudo perf top                # 实时热点预览(类似top)sudo perf record -g -p 1234  # 采样指定进程,-g记录调用栈sudo perf report             # 分析采样结果# 生成火焰图git clone https://github.com/brendangregg/FlameGraphsudo perf record -g -p 1234 -- sleep 30sudo perf script | ./FlameGraph/stackcollapse-perf.pl | ./FlameGraph/flamegraph.pl > flame.svg

三、实战案例:线上Java服务CPU飙升诊断

需求背景:线上Java服务(data-processor)CPU从15%飙升至85%,响应时间从50ms涨到800ms,需快速定位根因。

方案设计:使用top/htop快速定位 → sar回溯历史 → perf深度剖析

# 步骤1:登录服务器,用top快速确认top -c# 发现PID 12345的java进程CPU 95%# 步骤2:用htop查看线程级详情htop -p 12345 -H# 发现有个线程"GC task" CPU 90%,初步怀疑:频繁GC# 步骤3:用sar查看历史负载sar -u -f /var/log/sysstat/sa09 | grep "14:2"# 发现14:20-14:25期间 %user 从10%升至80%# 步骤4:用perf深度剖析sudo perf record -g -p 12345 -- sleep 30sudo perf report# 输出显示:70%时间在G1GC的concurrent marking# 步骤5:验证并解决jstat -gcutil 12345 1000 5# 发现Old区使用率95%,确认内存不足# 解决:增加堆内存 -Xmx4g → -Xmx8g

四、经验总结

最佳实践清单:

  • 监控先行:生产环境必须部署监控系统(Prometheus+Grafana),设置告警阈值

  • 工具组合拳:top(实时)+ sar(历史)+ perf(深度),覆盖全场景

  • 数据留存:sar默认只保存7天,建议调整到28天以上

  • 脚本化采集:top -b -n 1适合脚本采集,避免交互操作风险

进阶学习路径:掌握基础监控工具 → 学习perf和火焰图 → 部署监控系统 → 学习eBPF

- 完 -

感谢阅读!对您有帮助的话,点亮👍🏻❤️,关注公众号,转发给需要的朋友~ 原创转载请联系授权。

最新文章

随机文章