🍃 予枫：个人主页
📚 个人专栏: 《Java 从入门到起飞》《读研码农的干货日常》

💻 Debug 这个世界，Return 更好的自己！

---

引言

做Linux运维、后端开发的同学，肯定遇到过这些难题：服务器突然卡顿、程序莫名OOM崩溃、磁盘提示空间不足、挂载分区重启后失效……其实这些问题，大多和内存或磁盘IO有关。今天就手把手教大家，用free、df、iostat、mount这几个核心命令，搞定内存与磁盘IO的全场景排查，从底层逻辑到实操落地，新手也能直接抄作业，建议点赞收藏，避免用到时找不到！

一、内存分析：free -h详解+OOM排查，吃透Buffer与Cache

内存是服务器的“临时仓库”，程序运行全靠它，一旦内存不足或使用异常，就会出现卡顿、崩溃等问题。而free命令，就是我们排查内存问题的“第一把手”。

1.1 free -h 命令详解（最常用姿势）

先上实操命令，直接在终端输入以下指令，就能查看内存使用情况：

free -h

这里的-h参数是“human-readable”的缩写，意思是用人类易读的单位（KB/MB/GB）显示，避免查看一串冗长的数字。

运行后会输出类似以下结果（重点看标注部分）：

              total        used        free      shared  buff/cache   available
Mem:           15Gi       2.3Gi        10Gi       152Mi       2.7Gi        12Gi
Swap:         19Gi          0B        19Gi

逐个解析每一列的含义，新手也能轻松看懂：

• total：总内存大小（这里是15Gi），即服务器物理内存的总容量；
• used：已使用内存（2.3Gi），包括正在运行的程序、内核占用的内存；
• free：完全空闲的内存（10Gi），未被任何程序或系统占用；
• shared：共享内存（152Mi），多程序共享使用的内存，一般占用较少；
• buff/cache：缓冲区（Buffer）+ 缓存（Cache）的总大小（2.7Gi），这是重点，下面单独详解；
• available：可用内存（12Gi），真正能被新程序使用的内存，= free + buff/cache中可回收部分。

⚠️ 重点提醒：很多新手会把“free”当作“可用内存”，其实不对！真正能用来启动新程序的是“available”，因为buff/cache中的内容是可以被系统回收的，不用担心buff/cache占用过高。

1.2 Buffer 与 Cache 的区别（新手必懂，避免混淆）

很多人看到buff/cache就头疼，分不清两者的作用，其实用一句话就能分清：

Buffer 是“临时存放要写入磁盘的数据”，Cache 是“临时存放从磁盘读取的数据”。

举两个通俗的例子，帮你吃透底层逻辑：

1. 你用编辑器写文章，每敲一个字，系统不会立刻把字写入磁盘，而是先存到Buffer里，等你保存时，再一次性把Buffer里的数据写入磁盘——这样做是为了减少磁盘IO次数，提升效率；
2. 你第一次打开一个很大的日志文件，加载会很慢，因为要从磁盘读取数据；但你第二次打开，速度会快很多，因为系统已经把第一次读取的数据存到Cache里了，直接从Cache读取，不用再访问磁盘。

总结：Buffer 面向“写入”，Cache 面向“读取”，两者都是为了减少磁盘IO，提升系统运行效率。如果buff/cache占用过高，无需担心，系统会在内存不足时自动回收。

1.3 OOM（Out of Memory）现象与排查步骤

OOM，也就是“内存溢出”，是程序员和运维最头疼的问题之一——程序因为申请不到足够的内存，被系统强制杀死，出现“程序莫名崩溃”“进程消失”的情况。

1.3.1 OOM 常见现象

• 程序突然退出，查看日志会出现“Out of memory: Kill process XXX”的提示；
• 服务器卡顿严重，top命令查看内存，used接近total，available趋近于0；
• 部分服务无法启动，提示“Cannot allocate memory”（无法分配内存）。

1.3.2 OOM 排查核心步骤（实操落地，直接套用）

1. 查看内存使用情况，确认是否真的内存不足：

   free -h  # 查看整体内存
   top      # 实时查看进程内存占用，按M键按内存排序
   

   通过top命令，找到内存占用最高的进程（PID和进程名），判断是否是异常进程（比如某个程序内存泄漏，占用率持续飙升）。

2. 查看OOM日志，定位具体崩溃的进程和原因：

   dmesg | grep -i oom  # 查看系统OOM日志，grep过滤相关内容
   

   日志中会显示被杀死的进程PID、进程名，以及当时的内存使用情况，帮助我们定位是哪个程序导致的OOM。

3. 针对性解决（3种常见场景）：

   • 场景1：程序内存泄漏（比如Java程序、Python脚本）——排查代码，修复内存泄漏问题，或重启程序临时缓解；
   • 场景2：物理内存不足——升级服务器内存，或配置Swap分区（虚拟内存），临时充当内存使用；
   • 场景3：异常进程占用——杀死异常进程（kill -9 PID），并排查进程异常启动的原因。

💡 小技巧：如果经常出现OOM，可以配置OOM Killer（内存溢出杀手）规则，指定某些核心进程不被杀死，优先杀死非核心进程。

二、磁盘IO分析：df、du、iostat 命令实操，定位IO瓶颈

如果说内存是“临时仓库”，那磁盘就是“永久仓库”，磁盘IO（读写操作）是系统性能的另一个核心瓶颈——磁盘读写太慢，会导致程序加载缓慢、文件保存卡顿、数据库查询延迟。

下面三个命令，覆盖磁盘空间查看、目录大小统计、IO瓶颈排查，缺一不可。

2.1 df -h：查看磁盘空间使用情况（快速定位磁盘满）

当服务器提示“磁盘空间不足”时，第一个要用到的命令就是df -h，快速查看各个分区的空间使用情况。

实操命令：

df -h

输出结果类似以下内容：

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40Gi   12Gi   26Gi  32% /
/dev/vdb1       100Gi   45Gi   50Gi  48% /data
tmpfs           7.5Gi     0  7.5Gi   0% /dev/shm

核心参数解析：

• Filesystem：磁盘分区名称（比如/dev/vda1是系统根分区）；
• Size：分区总大小（比如根分区40Gi）；
• Used：已使用空间（12Gi）；
• Avail：可用空间（26Gi）；
• Use%：空间使用率（32%），重点关注——使用率超过90%，就会出现磁盘满、无法写入的问题；
• Mounted on：分区挂载点（比如根分区挂载在/目录，/data分区挂载在/data目录）。

⚠️ 注意：如果某个分区的Use%接近100%，要及时清理磁盘垃圾（比如日志文件、临时文件），避免影响服务正常运行。

2.2 du -sh：统计目录/文件大小（找到磁盘占用“元凶”）

df -h只能看到整个分区的空间使用情况，但不知道具体是哪个目录、哪个文件占用了大量空间。这时候，du -sh命令就派上用场了，能快速统计指定目录或文件的大小。

2.2.1 核心实操命令（高频用法）

1. 统计当前目录的总大小（简洁显示）：

   du -sh
   

   输出类似：12Gi .，表示当前目录总大小为12Gi。

2. 统计指定目录的大小（比如/data目录）：

   du -sh /data
   

3. 统计当前目录下所有子目录的大小（按大小排序，找到占用最大的目录）：

   du -sh * | sort -rh
   

   解析：

   • du -sh *：统计当前目录下每个子目录/文件的大小；
   • sort -rh：按大小逆序排序（r=逆序，h=人类易读单位），这样占用最大的目录会排在最前面。

2.2.2 实用场景

比如，通过df -h发现/data分区使用率达到90%，用以下命令快速定位“元凶”：

cd /data  # 进入/data分区
du -sh * | sort -rh  # 查看所有子目录大小，排序后找到最大的目录

比如发现/data/logs目录占用了60Gi，再进入logs目录，查看具体是哪个日志文件过大，然后清理无用日志即可。

💡 小技巧：清理日志时，不要直接删除正在写入的日志文件（会导致程序日志丢失），可以用echo "" > 日志文件名清空日志内容，既释放空间，又不影响程序运行。

2.3 iostat：排查磁盘IO瓶颈（磁盘读写太慢？看这里）

有时候，磁盘空间充足，但服务器依然卡顿、程序加载缓慢，这很可能是磁盘IO瓶颈导致的——磁盘读写速度跟不上程序的需求，出现“IO等待”。

iostat命令能实时查看磁盘IO的使用情况，帮我们定位IO瓶颈。

2.3.1 安装与实操命令

如果输入iostat提示“command not found”，先安装sysstat工具（包含iostat命令）：

# CentOS/RHEL系统
yum install -y sysstat

# Ubuntu/Debian系统
apt-get install -y sysstat

安装完成后，执行以下命令查看磁盘IO情况：

iostat -x 1 3

解析参数：

• -x：显示详细的IO统计信息（重点，包含IO使用率、读写速度等）；
• 1：每隔1秒刷新一次；
• 3：总共刷新3次，方便观察实时变化。

2.3.2 核心指标解析（重点看这3个）

输出结果中，重点关注以下3个指标，判断是否存在IO瓶颈：

1. %util：磁盘IO使用率（核心指标）——表示磁盘正在处理IO请求的时间占比；
   • 正常值：≤70%；
   • 异常值：≥80%，表示磁盘IO压力过大，存在瓶颈，会导致系统卡顿。
2. rMB/s、wMB/s：磁盘读、写速度（单位：MB/s）——反映磁盘读写的实际速度，结合业务判断是否满足需求；
3. await：IO请求等待时间（单位：ms）——表示IO请求从发出到完成的总时间；
   • 正常值：≤50ms；
   • 异常值：≥100ms，说明IO请求等待时间过长，磁盘响应太慢。

2.3.3 排查思路

如果通过iostat发现%util≥80%、await≥100ms，说明存在IO瓶颈，可按以下步骤排查：

1. 找到IO占用最高的磁盘（通过iostat输出的Device列，找到%util最高的磁盘）；
2. 找到占用该磁盘IO的进程（用iotop命令，需安装，能实时查看进程IO占用）；
3. 针对性优化：
   • 场景1：数据库（MySQL、PostgreSQL）占用过高——优化SQL语句、增加索引、调整数据库IO参数；
   • 场景2：大量文件读写（比如日志写入、文件上传）——拆分文件、使用缓存、升级磁盘（比如机械硬盘换SSD）。

三、挂载实操：mount 命令+ /etc/fstab 自动挂载，避免重启失效

在Linux中，磁盘分区、U盘、外接硬盘等设备，需要“挂载”到某个目录下，才能被系统识别和使用。如果只是用mount命令临时挂载，服务器重启后，挂载会失效——这是很多运维新手常踩的坑。

下面详解临时挂载、永久挂载（/etc/fstab配置），以及挂载避坑技巧。

3.1 mount 命令：临时挂载设备（快速生效，重启失效）

3.1.1 核心语法

mount [设备路径] [挂载目录]

3.1.2 实操案例（挂载/dev/vdb1到/data目录）

1. 先查看系统中已识别的磁盘设备（找到要挂载的设备路径）：

   lsblk  # 查看所有磁盘设备，输出清晰，新手首选
   

   输出中，找到要挂载的设备（比如/dev/vdb1）。

2. 创建挂载目录（如果目录不存在）：

   mkdir -p /data  # -p参数：如果目录不存在，自动创建
   

3. 临时挂载设备：

   mount /dev/vdb1 /data
   

4. 验证挂载是否成功：

   df -h  # 查看挂载情况，若能看到/dev/vdb1挂载在/data目录，说明挂载成功
   

⚠️ 注意：临时挂载仅当前生效，服务器重启后，/dev/vdb1会自动卸载，/data目录会变成空目录——如果是核心业务目录，千万不要用临时挂载！

3.2 /etc/fstab 配置：永久挂载（重启不失效，核心用法）

要实现“重启后依然保持挂载”，需要修改/etc/fstab文件，将挂载信息写入该文件，系统重启时会自动读取配置，完成挂载。

3.2.1 核心配置步骤（实操落地，一步到位）

1. 查看设备的UUID（推荐用UUID挂载，比设备路径更稳定，避免设备路径变化导致挂载失败）：

   blkid /dev/vdb1
   

   输出类似：/dev/vdb1: UUID="12345678-1234-1234-1234-1234567890ab" TYPE="ext4"，复制UUID值。

2. 编辑/etc/fstab文件（用vim编辑，需root权限）：

   vim /etc/fstab
   

3. 在文件末尾添加一行配置（格式如下，按实际情况修改）：

   UUID=12345678-1234-1234-1234-1234567890ab  /data  ext4  defaults  0  0
   

   逐字段解析（新手必懂，避免配置错误）：

   • UUID=xxx：刚才复制的设备UUID，唯一标识该磁盘，避免设备路径变化导致挂载失败；
   • /data：挂载目录，即设备要挂载到的目录；
   • ext4：文件系统类型（常见的有ext4、xfs，可通过blkid命令查看TYPE字段）；
   • defaults：挂载选项，默认值即可（包含rw、suid、dev等，满足大部分场景）；
   • 0：dump备份参数，0表示不备份，1表示备份（一般设为0）；
   • 0：fsck检查参数，0表示不检查，1表示优先检查，2表示次要检查（根分区设为1，其他分区设为2或0）。

4. 验证配置是否正确（避免配置错误导致系统无法启动）：

   mount -a
   

   • 如果没有报错，说明配置正确，系统会自动挂载/etc/fstab中新增的设备；
   • 如果报错，检查UUID、挂载目录、文件系统类型是否正确。

5. 再次验证挂载情况：

   df -h  # 确认/dev/vdb1已挂载到/data目录
   

3.2.2 避坑提醒（重中之重）

1. 配置/etc/fstab前，一定要先通过mount -a验证配置，避免配置错误导致服务器重启后无法启动；
2. 不要随意删除/etc/fstab中的原有配置，否则会导致系统分区无法挂载，服务器无法启动；
3. 如果要卸载永久挂载的设备，先删除/etc/fstab中对应的配置，再执行umount /data卸载，避免重启后自动挂载。

四、总结

本文围绕Linux内存与磁盘IO分析，从命令实操到场景排查，覆盖了3大核心模块：

1. 内存分析：用free -h吃透内存使用情况，分清Buffer与Cache，掌握OOM排查步骤，解决程序崩溃、内存不足问题；
2. 磁盘IO分析：用df -h查看磁盘空间，du -sh定位磁盘占用元凶，iostat排查IO瓶颈，解决磁盘满、读写卡顿问题；
3. 挂载实操：用mount临时挂载，用/etc/fstab实现永久挂载，避免重启失效，解决设备挂载踩坑问题。

所有命令均为运维、后端开发高频用法，新手可以直接抄作业，建议点赞收藏，遇到内存、磁盘相关问题时，直接对照本文排查，高效解决问题。