1. 引言为什么你需要掌握系统资源监控如果你在Ubuntu上跑过服务、部署过应用或者仅仅是觉得电脑突然变慢了那你大概率遇到过这样的场景终端里敲命令响应慢得像在爬浏览器开几个标签页风扇就开始狂转后台跑个脚本不知道它到底吃了多少内存。这时候你需要的不是重启大法而是一双能看清系统内部状况的“眼睛”。掌握查看系统资源占用的技能就是给你自己装上这双眼睛。这不仅仅是运维工程师的专利。对于开发者来说它是定位性能瓶颈、优化代码的第一手资料对于普通用户它是判断“电脑是不是该升级了”或者“哪个软件是拖慢系统的元凶”的直接依据。CPU、内存、网络这三者是现代计算系统的核心资源三角任何一个出现瓶颈都会直接影响你的使用体验和工作效率。网上教程很多但往往只告诉你一两个命令比如top或htop然后罗列一堆参数就结束了。这就像只给了你一把螺丝刀却没告诉你哪颗螺丝该拧。实际工作中你需要的是一个工具箱以及知道在什么情况下该用哪件工具。今天我们就来彻底搞懂在Ubuntu上监控系统资源的那些事从最基础的命令到进阶的组合拳让你不仅能“看到”更能“看懂”和“解决”。2. 核心监控工具全景图从命令行到图形界面在深入每个资源之前我们有必要先建立一个全局视角。Ubuntu下的资源监控工具大致可以分为三类经典的命令行工具、增强型交互工具以及图形化工具。每类工具都有其最佳使用场景。2.1 经典命令行“三剑客”top, vmstat, netstat这三个命令历史悠久几乎存在于所有Linux发行版中是排查问题的基本功。top命令是你打开终端后第一个应该想到的工具。它提供了一个动态、实时更新的系统进程和资源使用情况视图。运行top后你会看到几块关键信息系统概要区最上面几行显示了系统运行时间、登录用户数、系统平均负载load average以及CPU和内存的使用情况汇总。平均负载的三个数字如 0.05, 0.10, 0.15分别代表过去1分钟、5分钟、15分钟的平均负载对于多核CPU这个数值需要除以核心数来理解其繁忙程度。进程列表区下面则是各个进程的详细信息默认按CPU使用率降序排列。关键列包括PID: 进程ID。%CPU: 进程占用的CPU时间百分比。%MEM: 进程使用的物理内存百分比。COMMAND: 启动此进程的命令行。vmstatvirtual memory statistics则侧重于内存、进程、CPU活动等系统整体指标。它的优势在于可以以固定间隔采样适合观察一段时间内的趋势。例如vmstat 2 5表示每隔2秒采样一次共采样5次。输出中的siswap in和soswap out如果持续大于0就是内存不足、开始使用交换空间的明确信号这是系统变慢的一个重要原因。netstat曾经是查看网络连接、路由表、接口统计信息的瑞士军刀。虽然在新系统中逐渐被功能更强大的ss命令取代但它依然广泛使用。netstat -tunlp可以列出所有TCP/UDP监听端口以及对应的进程是排查“端口被谁占了”问题的利器。2.2 增强型交互工具htop, glances, nmon如果你觉得top的界面不够友好那么htop绝对是你的菜。它可以说是top的现代化增强版具有彩色输出、鼠标支持、垂直和水平滚动、树状视图显示进程关系等特性。你可以直接用方向键选择进程按F9发送信号如终止进程按F2进入设置界面用户体验提升巨大。安装也简单sudo apt install htop。glances是一个跨平台的、基于curses库的系统监控工具它在一个屏幕上用不同的颜色高亮显示了几乎所有的关键信息CPU、内存、负载、网络I/O、磁盘I/O、以及最消耗资源的进程列表。它还能以客户端/服务器模式运行方便远程监控。安装命令sudo apt install glances。nmon则是性能分析人士的最爱尤其擅长将性能数据记录到文件供事后分析。它同样提供实时视图可以非常直观地查看CPU、内存、网络、磁盘等数十种指标。你可以通过sudo apt install nmon安装然后运行nmon通过按单键如cfor CPU,mfor Memory,nfor Network来切换不同资源的视图。2.3 图形化工具系统监视器与GNOME System Monitor对于桌面用户Ubuntu自带的“系统监视器”GNOME System Monitor是一个零学习成本的完美选择。你可以在应用菜单中直接搜索打开。它提供了三个标签页进程类似htop的图形化列表可以排序、搜索、结束进程。资源以历史图表的形式展示CPU、内存和网络的历史使用情况非常直观。文件系统显示磁盘空间的使用情况。它的优势在于可视化能让你一眼就看到历史趋势比如内存使用量是否在缓慢增长可能存在内存泄漏或者网络活动是否在某个时间点出现峰值。提示在服务器环境或无图形界面的系统中命令行工具是你的唯一选择。而在日常桌面使用中结合图形化工具快速概览和命令行工具深度排查效率最高。3. 深度剖析CPU使用情况CPU是系统的大脑其使用率是衡量系统繁忙程度的核心指标。但看CPU使用率不能只看一个总的百分比。3.1 理解CPU使用率的构成在top或htop中CPU一行通常会显示如下的信息%Cpu(s): 12.5 us, 6.2 sy, 0.0 ni, 81.0 id, 0.2 wa, 0.0 hi, 0.0 si, 0.0 st。这些缩写代表us(user): 运行用户空间进程也就是你的应用程序所花费的时间百分比。sy(system): 运行内核空间进程系统调用所花费的时间百分比。如果这个值持续很高可能意味着内核在处理大量I/O或进程调度。id(idle): CPU空闲时间百分比。这是你最希望看到的数字越高说明系统越“轻松”。wa(iowait): CPU等待I/O通常是磁盘I/O完成的时间百分比。这是一个非常关键的指标。如果wa持续很高比如超过20%而id很低即使总的CPU使用率不高系统也会感觉非常卡顿因为CPU都在“空转”等待慢速的磁盘。这时候瓶颈在磁盘而不是CPU。st(steal): 在虚拟化环境中如云服务器被宿主机“偷走”的时间百分比。如果你的虚拟机性能不稳定可以关注这个值是否过高。所以当你发现系统卡顿时首先看wa和id。高wa指向磁盘问题低id且高us/sy才是真正的CPU算力不足。3.2 使用pidstat进行进程级CPU追踪top和htop能告诉你哪个进程现在最耗CPU但如果你想知道一个进程在一段时间内的平均CPU消耗或者想监控某个特定进程pidstat是更好的工具。它是sysstat软件包的一部分需要安装sudo apt install sysstat。例如你想每2秒采样一次共采样10次并查看所有进程的CPU使用情况pidstat -u 2 10。如果你想监控特定进程如PID为1234可以pidstat -u -p 1234 2 10。它的输出包含了用户态和内核态的CPU时间能更精细地分析进程行为。3.3 实战定位CPU占用飙升的“元凶”假设你的服务器在凌晨突然收到告警CPU使用率持续超过90%。你通过SSH登录后应该如何排查快速概览首先运行top按1键数字1展开所有CPU核心的单独显示看是单个核心打满还是所有核心都高。同时观察wa值排除磁盘I/O瓶颈。定位进程在top视图中进程默认按%CPU排序排在第一位的很可能就是“元凶”。记下它的PID和COMMAND。深入分析进程如果进程是Java/Python等解释型语言高CPU可能意味着陷入死循环或复杂计算。你可以用pidstat对该PID进行细粒度采样或者使用更专业的工具对于Java进程使用jstack pid获取线程堆栈结合top -H -p pid查看哪个线程CPU高然后将线程ID十进制转换为十六进制在jstack的输出中搜索就能定位到问题代码行。对于其他进程可以使用strace -cp pid来统计系统调用看是否在频繁执行某些调用。历史回溯如果问题已经发生你可以查看/var/log/syslog或系统的监控历史数据如果部署了Prometheus、Zabbix等看问题发生时间点附近有哪些日志或事件。一个我踩过的坑有一次一个后台数据处理服务CPU持续100%top显示是一个Python进程。用strace发现它在疯狂进行stat系统调用。最后发现是代码中一个目录遍历的逻辑错误在循环里反复检查一个不存在的目录导致无意义的系统调用风暴。修复循环判断条件后CPU使用率立刻降到1%以下。4. 全面掌握内存使用分析内存管理是Linux系统中最精妙也最容易让人困惑的部分。free -m命令显示的内存信息就经常引发误解。4.1 解读free命令你的内存真的被用光了吗运行free -h-h表示人类可读格式你会看到类似下面的输出total used free shared buff/cache available Mem: 7.7Gi 2.1Gi 1.5Gi 345Mi 4.0Gi 5.0Gi Swap: 2.0Gi 0.0Ki 2.0Gi关键是要理解每一列的含义total: 物理内存总量。used: 已使用的内存。注意这个值包含了buffers和cached所以它往往很大。free: 完全未被使用的内存。这个值小不一定代表内存紧张。buff/cache: 这是核心所在。buffers是内核缓冲区用的内存cache是页缓存和slab。简单理解这部分内存被用来缓存磁盘数据和内核对象目的是加速系统性能。当应用程序需要更多内存时这部分缓存可以被立刻回收。所以它不算“被占用”。available:这才是判断内存是否充足的关键指标。它估算的是在不使用交换空间的情况下可以分配给新应用程序的内存大小。它等于free 可回收的buff/cache。上例中虽然used显示2.1Gfree只有1.5G但available高达5.0G说明内存非常充裕。Swap: 交换分区使用情况。如果used持续增长说明物理内存确实不足系统开始把不常用的内存页换出到磁盘这会导致性能严重下降。所以看内存压力首要关注available和Swap used而不是free。4.2 深入/proc文件系统smem与/proc/meminfo/proc是一个虚拟文件系统提供了内核内部数据的接口。/proc/meminfo文件包含了最详细的内存统计信息。free和top等命令的数据都来源于此。直接cat /proc/meminfo可以看到MemTotal,MemFree,Buffers,Cached,SwapCached等数十个指标适合深度分析。smem是一个更直观的工具它能显示进程的内存使用情况并且按照不同的计算方式如PSS、USS呈现。PSSProportional Set Size对于共享内存的计算更合理是衡量进程实际占用物理内存的更好指标。安装sudo apt install smem。使用smem -t -p可以以百分比和表格形式查看一目了然。4.3 实战诊断内存泄漏与OOM Killer内存泄漏是后台服务常遇到的问题。症状通常是available内存随时间缓慢但持续地减少即使服务负载没有增加。重启服务后内存恢复正常但几天后又慢慢涨上去。排查步骤确认泄漏使用watch -n 5 ‘free -h‘命令每5秒刷新一次内存情况观察available和buff/cache的变化趋势。如果available持续下降而buff/cache变化不大基本可以断定是应用程序内存泄漏而非系统缓存增长。定位泄漏进程使用smem或htop按内存使用排序观察哪个进程的RES常驻内存或PSS在持续增长。对于容器环境可以使用docker stats。分析进程内部如果是Java进程可以使用jmap -histo:live pid查看堆内存中的对象分布或者使用jcmd pid GC.heap_info。结合监控工具如VisualVM, JMC进行实时堆转储分析是更有效的方法。应对OOM Killer当系统内存严重不足时Linux内核的“Out-Of-Memory Killer”会被触发它会选择一个“最不重要”的进程杀死以释放内存。被杀的进程会在/var/log/kern.log或dmesg输出中留下记录搜索Out of memory或Killed process。优化方向一是增加内存或优化应用二是通过调整/proc/pid/oom_score_adj来影响进程被选中的优先级值越低越不容易被杀。我曾经管理过一个Go语言写的API服务每隔一周左右就会因为内存泄漏被OOM Killer干掉。用smem观察到其PSS每天增长约200MB。最终使用pprof进行堆分析发现是一个全局的缓存map只增不减没有设计淘汰策略。增加了LRU淘汰机制后问题解决。5. 网络流量与连接监控网络问题往往更复杂因为它涉及本地连接、远程主机、协议和端口。监控网络主要关注两点流量带宽和连接状态。5.1 实时流量监控iftop, nload, vnstatiftop类似于top但是用于网络接口。它可以实时显示当前主机上各个网络连接的带宽使用情况按流量排序。安装sudo apt install iftop。运行sudo iftop -i eth0将eth0替换为你的网卡名即可。它能非常直观地告诉你“到底是哪个IP在疯狂上传/下载”。nload则更简洁它专注于显示每个网络接口的实时流量图表包括流入Incoming和流出Outgoing的实时速率、平均速率、最大速率以及数据总量。安装sudo apt install nload。运行nload eth0即可。vnstat是一个基于控制台的网络流量统计工具它的特点是轻量级、后台运行、统计历史数据。它不实时显示流量而是定期如每5分钟将网卡流量记录到数据库然后你可以查询每天、每周、每月的流量总计。安装后需要先为指定网卡初始化数据库sudo vnstat -i eth0 --create然后可以通过vnstat -d日、vnstat -m月等命令查看。这对于监控服务器月度流量消耗非常有用。5.2 连接状态分析ss命令的完全指南如前所述netstat已老sssocket statistics是它的现代替代品速度更快信息更详细。掌握ss的常用组合至关重要ss -tlnp: 查看所有监听LISTEN的TCP端口并显示对应的进程名和PID。这是查看本机开放了哪些服务端口的首选命令。ss -tunp: 查看所有TCP和UDP连接包括监听和非监听并显示进程信息。-u表示UDP。ss -s: 查看套接字统计摘要显示各种类型的连接总数快速了解系统连接概况。ss -o state established ‘( dport :443 or sport :443 )‘: 这是一个更高级的用法查看所有与443端口相关的已建立连接并显示定时器信息如keepalive时间。这对于排查连接不释放的问题很有帮助。5.3 实战排查服务器网络异常高连接数、端口占用场景服务器响应变慢怀疑是网络连接数过多或某个端口被异常占用。查看连接数概况运行ss -s。关注Total连接数是否异常高。如果TIME-WAIT状态连接特别多可能是短连接服务没有正确设置TCP参数如tcp_tw_reuse。定位异常连接运行ss -tunp | head -20查看当前活跃的连接。关注那些你不认识的远程IP或非常用端口。可以使用grep过滤例如ss -tunp | grep :8080查看所有涉及8080端口的连接。排查端口占用如果你想启动一个服务发现端口比如3000被占用运行sudo ss -tlnp | grep :3000。它会告诉你哪个进程的PID占用了这个端口。然后你可以用ps aux | grep PID找到具体的进程决定是否要终止它。监控实时流量如果怀疑有异常流量如被攻击或爬虫运行sudo iftop -i eth0。观察是否有单个IP在短时间内产生了巨大的流量。结合ss命令你可以找到该IP对应的连接和进程。一个常见的坑是“TIME-WAIT”堆积。我们的一个Web服务器在承受高并发压力测试后ss -s显示有上万个TIME-WAIT连接。这是因为HTTP短连接在关闭后会进入TIME-WAIT状态等待2MSL最大报文段生存时间通常2分钟以确保网络中旧的重复报文消散。对于高并发短连接服务这会导致端口资源快速耗尽。解决方案是调整内核参数如启用net.ipv4.tcp_tw_reuse和net.ipv4.tcp_timestamps让内核更积极地复用处于TIME-WAIT状态的套接字。但修改内核参数需要谨慎并充分测试。
