Linux系统资源监控实战：CPU、内存、磁盘性能排查与优化指南-开发者社区

1. 引言：为什么我们需要时刻关注系统资源？

作为一名长期与Linux服务器打交道的运维工程师或开发者，我敢说，查看CPU、内存和磁盘使用情况，是每天打开终端后做得最多的事情之一。这不仅仅是例行公事，更像是给系统做一次快速的“体检”。想象一下，你管理的线上服务突然响应变慢，用户投诉蜂拥而至，这时候你的第一反应是什么？没错，就是连上服务器，敲几个命令，看看是CPU被哪个进程吃光了，还是内存快爆了，亦或是磁盘空间告急。这些命令就是你的听诊器和血压计，能让你在几秒钟内定位到问题的症结所在。

无论是排查线上故障、评估服务器性能瓶颈、规划硬件升级，还是日常的服务器健康巡检，熟练掌握这些资源查看命令都是必备的基本功。很多人觉得这些命令简单，无非就是top、free、df，但真正用起来，里面的门道可不少。比如，top里看到的CPU使用率100%就一定代表性能瓶颈吗？free命令显示的“可用内存”为什么总是那么少？df和du查出来的磁盘使用量对不上又是怎么回事？今天，我就结合自己多年的实战经验，把这些命令里里外外讲透，不仅告诉你怎么用，更告诉你为什么这么用，以及如何解读那些容易让人误解的输出信息。

2. CPU使用情况深度剖析：不只是看一个百分比

CPU是系统的大脑，它的繁忙程度直接决定了系统的处理能力。在Linux下，我们有一系列工具来观察CPU的“工作状态”。

2.1 实时监控之王：top与htop

top命令是绝大多数人的首选。它提供了一个动态更新的全屏界面，展示系统概览和进程列表。

top

刚进入top界面，第一眼看到的汇总信息区（Summary Area）就包含了关键信息：

%Cpu(s): 这是CPU使用率的概览。它由多个部分组成：
- us(user): 运行在用户空间（非内核）的进程所占用CPU时间的百分比。你的应用程序，如Java、Python、Nginx，都算在这里。
- sy(system): 运行在内核空间的进程所占用CPU时间的百分比。系统调用、中断处理、内核线程（如ksoftirqd）的消耗在这里体现。
- id(idle): CPU空闲时间的百分比。这个值高通常是好事。
- wa(iowait): CPU等待I/O（通常是磁盘I/O）完成的时间百分比。这是一个非常重要的指标。如果这个值持续很高（比如超过5%-10%），往往意味着磁盘是系统瓶颈，CPU在“空转”等待数据。
- 其他如hi（硬中断）、si（软中断）、st（被虚拟化环境偷走的时间）等，在特定场景下也需要关注。

注意：很多人看到us或sy接近100%就紧张。这不一定代表有问题。如果系统正在执行一个计算密集型任务（如科学计算、视频编码），CPU利用率高是正常的。需要结合具体业务场景和响应时间来判断。真正需要警惕的是wa值过高，或者us/sy高但系统整体吞吐量很低的情况。

在进程列表区，默认按CPU使用率降序排列。你可以看到每个进程的%CPU（单个CPU核心的使用率百分比）、TIME+（累计占用CPU时间）等信息。

htop是top的增强版，界面更友好，支持鼠标操作、颜色高亮、树状视图查看进程关系，并且可以横向滚动查看完整的命令行。如果你的系统没有，通常可以通过包管理器安装（如yum install htop或apt install htop）。

htop

使用htop时，你可以按F6选择排序字段，按F5以树状结构显示进程，这对于理解父子进程关系非常有帮助。

2.2 简洁快照：mpstat与pidstat

有时我们不需要持续的界面，只需要一个时间点的快照，或者想查看每个CPU核心的独立情况。mpstat（Multiprocessor Statistics）命令就派上用场了。它是sysstat工具包的一部分，可能需要单独安装。

# 查看所有CPU核心的统计信息，每秒刷新一次，共刷新5次 mpstat -P ALL 1 5

这个命令的输出会清晰地列出每个逻辑CPU核心（包括超线程出来的核心）的%usr，%sys，%iowait，%idle等。这对于排查多核CPU负载不均的问题非常有用。比如，你可能发现只有一个核心的%sys特别高，这可能是某个进程或内核线程被固定在了某个核心上。

如果想查看具体是哪个进程在消耗CPU，pidstat是另一个利器，它也来自sysstat工具包。

# 每2秒报告一次所有进程的CPU使用情况 pidstat -u 2 # 查看特定进程（如PID为1234）的详细CPU使用，包括用户态和内核态 pidstat -u -p 1234 2 5

pidstat的优势在于它可以分离出进程在用户态(%usr)和内核态(%system)的CPU消耗，这对于分析程序性能瓶颈（是业务逻辑复杂还是系统调用频繁）非常有帮助。

2.3 性能剖析的利器：perf与火焰图

当发现某个进程CPU使用率异常高时，我们需要进一步深入，知道是进程内部的哪些函数在消耗CPU。这时就需要用到性能剖析（Profiling）工具。perf是Linux内核自带的强大性能分析工具。

一个常见的用法是使用perf top实时查看系统中消耗CPU最多的函数符号。

sudo perf top

更深入的做法是使用perf record采样并生成数据文件，然后用perf report分析，或者生成火焰图（Flame Graph）。火焰图能非常直观地展示出CPU时间在调用栈上的分布，一眼就能找到“最宽”的那个函数，即热点所在。

生成火焰图通常需要几个步骤：使用perf record采样，使用perf script转换数据，最后使用FlameGraph开源工具包中的脚本生成SVG图片。网上有大量关于“如何用火焰图分析CPU占用”的教程，这正是解决“wechatappex.exe占用cpu高”或“lsass.exe cpu占用率高”这类问题的终极手段之一。通过火焰图，你可以清晰地看到是哪个模块、哪个函数调用路径消耗了最多的CPU时间，从而进行针对性优化。

3. 内存使用情况详解：理解“已用”和“可用”的真相

Linux的内存管理非常复杂，也导致了很多误解。直接看free命令的输出，新手经常会吓一跳：“我的内存怎么用了这么多？可用内存只剩这么点了？”

3.1 解读free命令：Buffers和Caches才是关键

我们先看一个典型的free -h（-h表示人类可读格式）输出：

total used free shared buff/cache available Mem: 7.6G 1.2G 500M 200M 5.9G 6.0G Swap: 2.0G 0B 2.0G

total: 物理内存总量。
used: 已使用的内存。注意：这个值包含了buffers和cache，所以它通常很大。
free: 完全未被使用的内存。这个值小不一定代表内存紧张。
shared: 主要用于tmpfs等共享内存。
buff/cache: 这是理解Linux内存使用的核心。它是被内核用作**缓冲区（Buffers）和缓存（Caches）**的内存。
- Buffers: 主要用来缓存磁盘块的元数据（如inode、dentry）和临时存储即将写入磁盘的数据。
- Caches:Page Cache，缓存从磁盘读取的文件内容。当你多次读取同一个文件时，第二次及以后的速度会极快，就是因为数据在内存的Page Cache里。
available:这才是真正需要关注的“可用内存”指标。它估算的是在不进行Swap的情况下，可以分配给新应用程序的内存大小。它包含了free内存和大部分可被回收的buff/cache内存。上例中，虽然free只有500M，但available高达6.0G，说明内存非常充裕。

核心原理：Linux会利用所有空闲内存来做磁盘缓存（Cache），以提升系统性能。当应用程序需要更多内存时，内核会自动、快速地将这部分缓存内存释放给应用程序。所以，buff/cache占用的内存高是好事，是内存被高效利用的表现，而不是内存泄漏。

3.2 深入进程内存：/proc/pid/status与smem

free看的是全局，我们还需要看具体每个进程的内存使用。top或htop里可以看到RES（常驻内存）和VIRT（虚拟内存），但还不够细。

更详细的信息在/proc/[pid]/status文件里。例如，查看PID为1234的进程：

cat /proc/1234/status | grep -E ‘VmRSS|VmSize|VmSwap’

VmSize: 进程的虚拟内存大小（类似VIRT）。
VmRSS: 进程实际使用的物理内存大小（类似RES）。这是该进程独占的、未被共享的内存。
VmSwap: 进程被交换到Swap分区的内存大小。

另一个好用的工具是smem，它能展示进程的实际物理内存占用（PSS和USS），这对于评估共享库内存占用的应用（如多个Apache进程）非常有用。PSS（Proportional Set Size）将共享内存按比例分摊到各进程，比RSS更能反映真实内存压力。

3.3 排查内存泄漏与OOM

内存泄漏是服务器稳定性的一大杀手。持续观察free中的available趋势，如果它在系统负载无明显变化时持续下降，就可能存在内存泄漏。

更直接的方法是使用vmstat命令观察内存和Swap的动态变化：

vmstat 1

关注si（swap in，从磁盘交换到内存）和so（swap out，从内存交换到磁盘）两列。如果so长期大于0，说明物理内存不足，开始使用Swap了，这会严重拖慢系统性能。

当系统内存严重不足时，内核的OOM Killer（Out-Of-Memory Killer）会被触发，它会选择一个“最坏”的进程杀死以释放内存。可以通过dmesg | grep -i kill查看OOM Killer的历史记录。防止OOM的关键是合理设置应用程序的内存上限（如JVM的-Xmx参数），并确保/proc/sys/vm/overcommit_memory策略符合你的预期。

对于像“antimalware service executable占内存”或“chrome内存泄露”这类问题，思路是一样的：先用top或任务管理器找到高内存进程，再用更细的工具（如smem，或在Windows下用Process Explorer）分析其内存构成，判断是工作集正常膨胀还是持续增长的内存泄漏。

4. 磁盘使用与管理：从空间到I/O的全方位监控

磁盘问题通常分为两类：空间不足和I/O性能瓶颈。我们需要不同的工具来应对。

4.1 查看磁盘空间：df与du的配合与差异

查看磁盘空间使用率最常用的命令是df（disk filesystem）。

df -h

-h同样表示人类可读。这个命令显示的是文件系统层面的磁盘使用情况，即每个挂载点（如/，/home，/var）的总容量、已用量、可用量和使用百分比。当某个分区的使用率超过80%（甚至90%）时，就需要警惕了，这会影响系统运行和日志写入。

那么，是哪个目录或文件占用了大量空间呢？这就需要du（disk usage）命令来深入目录了。

# 查看当前目录下各子目录的大小 du -sh * # 查找当前目录下最大的10个文件或目录 du -ah | sort -rh | head -n 10

一个经典问题：为什么df显示磁盘用了90%，但用du -sh /统计根目录下所有文件的总和却远小于这个值？这通常有以下原因：

已删除但未释放的文件：如果有进程打开了一个大文件，然后这个文件被删除了，在进程关闭该文件句柄前，磁盘空间不会被释放。可以用lsof | grep deleted命令查找这类文件。
文件系统预留空间：Ext文件系统默认会为root用户保留5%的空间（可用tune2fs -l /dev/sda1 | grep ‘Reserved block count’查看），这部分空间df会算入已用，但du无法统计。
磁盘快照或稀疏文件：某些高级功能可能导致空间计算差异。

4.2 监控磁盘I/O性能：iostat与iotop

磁盘空间够，但系统还是很慢，top显示%wa很高，这很可能就是磁盘I/O瓶颈。iostat（也来自sysstat包）是分析磁盘I/O性能的标准工具。

# 每2秒刷新一次，显示扩展统计信息 iostat -dx 2

关键列解读：

%util: 设备利用率。表示设备有I/O请求的时间百分比。如果持续接近100%，说明设备I/O饱和，是性能瓶颈。
r/s，w/s: 每秒的读/写请求数。
rkB/s，wkB/s: 每秒读/写的数据量（KB）。
await: 平均每次I/O请求的等待时间（毫秒）。这个值高，说明磁盘响应慢。
svctm: 平均每次I/O请求的服务时间（毫秒）。通常应小于await。

如果iostat发现某个磁盘（如sdb）的%util和await很高，下一步就是找出是哪个进程在疯狂读写它。这时要用到iotop（可能需要安装）。

sudo iotop

iotop类似于top，但是用于显示实时磁盘I/O。你可以清楚地看到每个进程的读/写速率，从而定位到“罪魁祸首”。对于解决“system占用磁盘100%”这类问题，iostat配合iotop是黄金组合。

4.3 磁盘挂载与文件系统管理

在Linux中，磁盘需要挂载到目录树才能使用。mount命令可以查看当前已挂载的文件系统。而磁盘挂载工具，如经典的fdisk、parted，或图形化的gparted，用于对磁盘进行分区。在服务器上，我们更常用fdisk或parted进行命令行操作。

关于“linux磁盘挂载工具有哪些”，除了上述分区工具，挂载动作本身是通过mount命令完成的，而让挂载在开机时自动生效，则需要将配置写入/etc/fstab文件。这是一个需要谨慎操作的文件，错误的配置可能导致系统无法启动。

对于“搜狗磁盘管理”或“磁盘精灵”这类Windows下的工具，在Linux中对应的可能是gnome-disks（磁盘实用工具）或GParted，它们提供了图形化的分区、格式化、挂载和SMART检测功能，对于桌面用户更加友好。

5. 综合实战：一个典型的高负载故障排查流程

现在，让我们把这些命令串起来，模拟一个完整的故障排查场景：一台线上Web服务器突然响应变慢，请求大量超时。

第一步：快速全局概览首先，使用top或htop快速查看。

如果%Cpu(s)一行中wa值超过30%，甚至50%，初步怀疑磁盘I/O问题。
如果us或sy值异常高，则怀疑CPU计算瓶颈。
同时观察Mem行，看available内存是否充足，Swap是否开始使用（Si/So在vmstat中更直观）。

假设top显示%wa很高，且available内存充足。

第二步：定位I/O瓶颈源

打开另一个终端，运行iostat -dx 2。观察是哪个磁盘设备（比如/dev/sdb1）的%util和await指标异常高。
保持iostat运行，再开一个终端，运行sudo iotop。按o键只显示有I/O活动的进程。观察是哪个进程在对高负载的磁盘进行大量读写。假设发现是MySQL进程（mysqld）在大量写。

第三步：深入分析问题进程

用pidstat -d -p <mysql_pid> 2查看该进程详细的I/O统计。
同时，可以用mysql客户端连接数据库，执行SHOW PROCESSLIST;查看当前正在执行的慢查询，或者检查慢查询日志。很可能是某个没有索引的大表全表扫描，或者大量的磁盘临时表操作，导致了疯狂的磁盘写。

第四步：检查磁盘空间虽然I/O高，也顺带用df -h检查一下相关分区（比如/var， MySQL数据目录常在此）的空间是否足够。磁盘满也会导致写操作异常。

第五步：制定解决方案根据分析结果采取行动：

如果是慢查询导致，优化SQL语句，添加索引。
如果是日志写入过于频繁，考虑调整日志级别或轮换策略。
如果磁盘本身性能太差（如机械硬盘），考虑升级为SSD，或者将数据库的日志文件（如binlog、redo log）放到更快的磁盘上。

在整个过程中，你可能还会穿插使用vmstat 1监控内存和Swap，使用dmesg -T | tail查看内核有无报错信息。这套组合拳打下来，绝大多数资源类性能问题都能被定位。

6. 进阶工具与脚本化监控

对于需要长期监控的场景，我们不可能一直开着终端。这时就需要脚本化和使用更专业的监控系统。

简单的Shell脚本：可以写一个脚本，定期收集top、free、df、iostat的输出，保存到日志文件。

#!/bin/bash LOG_FILE=“/var/log/system_health_$(date +%Y%m%d).log” echo “=== $(date) ===” >> $LOG_FILE echo “— Top CPU Processes —” >> $LOG_FILE top -b -n 1 | head -20 >> $LOG_FILE echo “— Memory Usage —” >> $LOG_FILE free -h >> $LOG_FILE echo “— Disk Usage —” >> $LOG_FILE df -h >> $LOG_FILE

专业监控系统：如Zabbix、Prometheus + Grafana。它们可以持续采集服务器的CPU、内存、磁盘、网络等各项指标，并绘制成美观的图表，设置告警阈值。当CPU使用率超过80%持续5分钟，或者磁盘空间低于10%时，自动发送邮件或短信告警。这才是运维大规模集群的标配。

例如，Prometheus的node_exporter会暴露大量的系统指标，Grafana则可以配置丰富的仪表盘来展示“CPU智能核心调度”情况、每个核心的负载、内存的详细组成（active， inactive， slab等）、磁盘的IOPS和吞吐量趋势图。这远比手动执行命令要高效和全面。

7. 避坑指南与经验之谈

最后，分享一些容易踩坑的经验：

不要迷信free命令的free列：真正该看的是available。看到free内存少就慌，然后去盲目清理缓存（echo 3 > /proc/sys/vm/drop_caches），可能会造成短时间内性能下降，因为清理掉的缓存需要重新从磁盘加载。
理解CPU负载（Load Average）与使用率的区别：top第一行显示的load average: 1.05， 0.70， 0.65，分别代表过去1、5、15分钟的系统平均负载。对于单核CPU，1.0表示完全利用；对于4核CPU，4.0表示完全利用。它衡量的是处于可运行状态和不可中断状态的平均进程数。高负载可能由CPU繁忙、I/O等待（进程因等待磁盘而阻塞）等多种原因引起。所以高负载不一定等于高CPU使用率。
df和du结果不一致时：优先排查是否有进程占用了已删除的文件（lsof | grep deleted）。这是生产环境常见问题，尤其是日志文件被rm删除但服务进程未重启时。
警惕“软”RAID或LVM的性能问题：在虚拟机或云主机中，底层磁盘可能是网络存储或复杂的RAID。使用iostat时，如果看到await异常高但%util不高，可能意味着底层存储延迟高，而非本地磁盘瓶颈。
Swap的使用策略：完全禁用Swap在某些情况下（如内存充足且追求极致性能）可行，但保留少量Swap作为一个安全网是更通用的做法。当物理内存不足时，内核可以先将不活跃的内存页换出，避免直接触发OOM Killer导致关键进程被杀。可以通过/proc/sys/vm/swappiness来调整内核使用Swap的倾向性（值越大越积极使用Swap，默认通常是60）。