Linux 内存释放完全指南

在 Linux 系统运维中，“内存不够用”是最常见的问题之一。很多时候，系统明明配置了充足的物理内存，却频繁出现应用卡顿、响应延迟甚至 OOM（Out of Memory）杀死进程的情况。这并非单纯的“内存不足”，而是 Linux 独特的内存管理机制与实际业务负载不匹配导致的。

本文将从 Linux 内存管理的核心原理入手，详细拆解 6 类实用的内存释放方法，涵盖手动清理、参数调优、进程管理、应用优化等场景，并提供可直接落地的脚本和监控方案，帮助运维人员彻底解决内存占用过高的问题。

一、先搞懂：Linux 内存管理的“底层逻辑”
在学习“释放内存”之前，必须先明白 Linux 是如何管理内存的。否则，盲目操作不仅无法解决问题，还可能破坏系统的缓存机制，导致性能反降。

1.1 Linux 内存的“四大组成部分”
Linux 系统的内存（此处指物理内存）主要分为 4 个核心区域，通过 free -h 命令可直观查看：

内存区域 作用说明
Used（已用内存） 包括应用进程占用的内存、内核占用的内存、缓存和缓冲区，是“总内存 - 空闲内存 - 缓冲缓存”的结果。
Free（空闲内存） 完全未被使用的内存，Linux 会尽量减少这部分内存（空闲内存是“浪费”的）。
Buffer（缓冲区） 由内核用于临时存储“块设备数据”（如硬盘、U盘），比如读取磁盘文件时，先缓存到 Buffer 再给应用。
Cache（页缓存） 分为 Page Cache（文件内容缓存）和 Dentry Cache（文件目录/路径缓存），用于加速文件读写。
关键误区：很多人看到 free 命令中“Free 内存很少”就认为内存不足，这是错误的。因为 Cache/Buffer 是“可回收内存”——当应用需要内存时，内核会自动释放这部分内存给应用，无需手动干预。

1.2 虚拟内存与 Swap：内存的“后备军”
为了应对物理内存不足的情况，Linux 引入了“虚拟内存”机制，核心是 Swap（交换分区/文件）：

Swap 是硬盘上的一块区域，用于临时存放物理内存中“暂时不用的进程数据”。
当物理内存紧张时，内核会将部分不活跃的进程数据写入 Swap，释放物理内存给活跃进程；当进程需要时，再从 Swap 读回物理内存。
注意：Swap 的读写速度远慢于物理内存（硬盘速度 vs 内存速度），频繁使用 Swap 会导致系统卡顿，这也是需要优化的重点场景。

1.3 查看内存状态的“核心命令”
在释放内存前，必须先通过工具定位问题（是缓存过高？进程内存泄漏？还是 Swap 滥用？），常用命令如下：

命令 核心作用
free -h 快速查看内存、缓存、Swap 的使用情况（-h 表示“人类可读格式”，如 GB/MB）。
top/htop 实时监控进程的内存占用（按 M 键可按内存占用排序，htop 是 top 的增强版）。
vmstat 1 5 输出内存、Swap、IO 的统计信息（1 表示每秒刷新，5 表示刷新 5 次）。
slabtop 查看内核 Slab 缓存的使用情况（Slab 是内核用于存储小对象的缓存，如 inode、dentry）。
ps aux --sort=-%mem 按内存占用降序排列所有进程（%mem 列表示进程占用物理内存的百分比）。
二、方法一：手动释放“可回收缓存”（最常用）
Linux 内核默认不会主动释放 Cache/Buffer（因为缓存能加速文件读写），但在某些场景下（如需要紧急部署新应用、内存监控告警时），可以手动触发缓存回收。

2.1 核心原理：利用 vm.drop_caches 内核参数
Linux 提供了 vm.drop_caches 内核参数，用于手动清理不同类型的缓存。该参数有 3 个可选值，对应不同的清理范围：

1：仅清理 Page Cache（文件内容缓存）。
2：仅清理 Dentry 和 Inode 缓存（文件目录、索引缓存）。
3：清理 Page Cache + Dentry/Inode Cache（最彻底的缓存清理）。
2.2 操作步骤（需 root 权限）
步骤 1：先查看当前缓存占用
通过 free -h 确认 Cache 大小，例如：

[root@linux ~]# free -h
total used free shared buff/cache available
Mem: 31Gi 8.2Gi 1.5Gi 256Mi 21Gi 22Gi
Swap: 15Gi 0B 15Gi
AI写代码
bash
1
2
3
4
可见当前 Cache 占用 21Gi，可通过手动清理释放这部分内存。

步骤 2：执行缓存清理命令
根据需要选择清理范围，执行对应的命令（需 root 权限）：

清理 Page Cache（最安全，不影响文件目录）：
echo 1 > /proc/sys/vm/drop_caches
AI写代码
bash
1
清理 Dentry/Inode Cache（会影响文件路径查找速度，需谨慎）：
echo 2 > /proc/sys/vm/drop_caches
AI写代码
bash
1
清理所有可回收缓存（推荐紧急场景使用）：
echo 3 > /proc/sys/vm/drop_caches
AI写代码
bash
1
步骤 3：验证清理效果
再次执行 free -h，观察 Cache 列的数值变化，例如：

[root@linux ~]# free -h
total used free shared buff/cache available
Mem: 31Gi 8.3Gi 22Gi 256Mi 512Mi 22Gi
Swap: 15Gi 0B 15Gi
AI写代码
bash
1
2
3
4
可见 Cache 从 21Gi 降至 512Mi，Free 内存从 1.5Gi 增至 22Gi，清理成功。

2.3 注意事项（避免踩坑）
清理缓存不会影响应用运行：Cache 是“可回收”的，清理后仅会暂时降低文件读写速度（后续会重新缓存），不会导致应用崩溃。
不要频繁清理：缓存的核心作用是加速系统，如果频繁清理（如每分钟执行一次），会导致硬盘 IO 压力增大，反而降低系统性能。
清理前建议同步磁盘：虽然不是必须，但清理缓存前执行 sync 命令（将 Buffer 中的数据写入磁盘），可避免极少数情况下的数据丢失风险：
sync && echo 3 > /proc/sys/vm/drop_caches
AI写代码
bash
1
三、方法二：优化 Swap 配置，减少“内存换入换出”
Swap 的滥用是导致 Linux 系统卡顿的重要原因。如果物理内存充足，但系统仍频繁使用 Swap，需通过调整参数优化 Swap 行为。

3.1 核心参数：vm.swappiness（控制 Swap 使用倾向）
vm.swappiness 是 Linux 控制 Swap 使用频率的核心参数，取值范围为 0~100：

值越高：内核越倾向于使用 Swap（例如 100 表示优先将内存数据写入 Swap）。
值越低：内核越倾向于使用物理内存（例如 0 表示仅在物理内存不足时才使用 Swap，部分内核版本中 0 仍会少量使用 Swap）。
默认值：大多数 Linux 发行版（如 CentOS、Ubuntu）的默认 swappiness 值为 60，这个值对服务器场景偏激进（容易频繁使用 Swap）。

3.2 操作步骤：调整 swappiness
步骤 1：查看当前 swappiness 值
cat /proc/sys/vm/swappiness
# 输出示例：60
AI写代码
bash
1
2
步骤 2：临时调整（重启后失效）
适用于测试优化效果，命令如下（以调整为 10 为例，服务器场景推荐 10~20）：

sysctl -w vm.swappiness=10
AI写代码
bash
1
步骤 3：永久调整（重启后生效）
修改 /etc/sysctl.conf 文件，添加或修改 vm.swappiness 配置：

# 编辑配置文件
vi /etc/sysctl.conf

# 添加以下内容（值根据实际场景调整）
vm.swappiness=10

# 使配置生效
sysctl -p
AI写代码
bash
1
2
3
4
5
6
7
8
3.3 进阶：清理 Swap 中的数据（释放 Swap 空间）
如果 Swap 已占用过高（如超过 50%），且物理内存有空闲，可以手动将 Swap 中的数据“换回到”物理内存，释放 Swap 空间。

操作步骤：
确认物理内存有足够空闲（Free 内存 > Swap 已用内存）：
free -h
# 示例：Swap 已用 8Gi，Free 内存 20Gi，满足条件
AI写代码
bash
1
2
临时关闭 Swap（会将 Swap 数据写入物理内存）：
swapoff -a
AI写代码
bash
1
重新开启 Swap：
swapon -a
AI写代码
bash
1
验证 Swap 占用是否降低：
free -h
# 示例：Swap 已用从 8Gi 降至 0B
AI写代码
bash
1
2
注意：swapoff -a 过程中，系统会将 Swap 数据读回物理内存，此时可能会有短暂的 IO 升高，建议在业务低峰期执行。

四、方法三：清理“无用进程”与“内存泄漏进程”
内存占用过高的另一大原因是“无用进程”（如僵尸进程、已停止服务但未退出的进程）或“内存泄漏进程”（应用持续占用内存且不释放）。这类问题无法通过清理缓存解决，必须针对性处理进程。

4.1 识别高内存占用进程
首先通过 ps 或 htop 找到占用内存过高的进程：

方法 1：用 ps 按内存占用排序
ps aux --sort=-%mem | head -10
AI写代码
bash
1
输出字段说明：

%mem：进程占用物理内存的百分比（核心参考指标）。
pid：进程 ID（后续杀死进程需要）。
comm：进程名称（判断进程用途）。
方法 2：用 htop 实时查看（更直观）
如果未安装 htop，先执行安装命令：

# CentOS/RHEL
yum install -y htop

# Ubuntu/Debian
apt install -y htop
AI写代码
bash
1
2
3
4
5
运行 htop 后，按 M 键按内存占用降序排列，红色标注的进程为内存占用较高的进程。

4.2 处理“僵尸进程”（Zombie Process）
僵尸进程是指“子进程已退出，但父进程未回收其资源”的进程，会占用少量内存（主要是进程表项），若数量过多会导致系统无法创建新进程。

步骤 1：查找僵尸进程
ps aux | grep -w Z
# 输出示例：1234 pts/0 00:00:00 python <defunct>（<defunct> 表示僵尸进程）
AI写代码
bash
1
2
步骤 2：杀死僵尸进程的父进程
僵尸进程本身无法直接杀死（因为已退出），需找到其“父进程”并杀死父进程：

查看僵尸进程的父进程 ID（PPID）：
ps -o ppid= 1234 # 1234 是僵尸进程的 PID
# 输出示例：456（父进程 PID）
AI写代码
bash
1
2
杀死父进程（需确认父进程是否无用）：
kill -9 456 # -9 表示强制杀死
AI写代码
bash
1
验证僵尸进程是否消失：
ps aux | grep -w Z
AI写代码
bash
1
4.3 处理“内存泄漏进程”
内存泄漏进程的特征是：%mem 持续升高，且即使没有业务请求，内存也不释放（如 Java 应用的堆内存持续增长）。

处理方案：
临时解决：重启泄漏进程（适用于紧急场景）：
# 先停止进程（以 Java 应用为例）
systemctl stop tomcat

# 再启动进程
systemctl start tomcat
AI写代码
bash
1
2
3
4
5
根本解决：排查内存泄漏原因（需开发配合）：
对于 Java 应用：使用 jmap、jstack 工具生成堆转储文件（heap dump），分析泄漏的对象和代码路径。
对于 C/C++ 应用：使用 valgrind 工具检测内存泄漏点。
对于 Python 应用：使用 memory_profiler 库分析代码中的内存占用情况。
五、方法四：内核参数调优，优化内存回收策略
除了 vm.drop_caches 和 vm.swappiness，Linux 还有多个内核参数可调整内存回收策略，从“源头”减少内存占用过高的问题。

5.1 核心调优参数说明
参数名称 作用说明 推荐值（服务器场景）
vm.vfs_cache_pressure 控制内核回收 Dentry/Inode 缓存的倾向（值越高，越容易回收）。 50~100（默认 100）
vm.min_free_kbytes 设置系统保留的“最小空闲内存”（避免内存完全耗尽导致系统无响应）。 物理内存的 1%~2%
vm.overcommit_memory 控制内存过度分配策略（避免应用申请过多内存导致 OOM）。 2（默认 0）
5.2 具体调优步骤
1. 调整 vm.vfs_cache_pressure（优化目录缓存回收）
默认值 100 表示内核对 Dentry/Inode 缓存的回收倾向与 Page Cache 一致。若系统目录文件多（如 NFS 服务器），可降低该值减少目录缓存回收，提升路径查找速度；若内存紧张，可提高该值加速回收。

# 临时调整
sysctl -w vm.vfs_cache_pressure=50

# 永久调整（添加到 /etc/sysctl.conf）
echo "vm.vfs_cache_pressure=50" >> /etc/sysctl.conf
sysctl -p
AI写代码
bash
1
2
3
4
5
6
2. 调整 vm.min_free_kbytes（保留最小空闲内存）
该参数设置系统必须保留的空闲内存，防止内存完全耗尽时，内核无法分配内存给关键进程（如 sshd、syslog）。

计算方式：若物理内存为 32Gi，推荐设置为 3210241024*1% = 33554432 KB（约 32MB）。

# 临时调整
sysctl -w vm.min_free_kbytes=33554432

# 永久调整
echo "vm.min_free_kbytes=33554432" >> /etc/sysctl.conf
sysctl -p
AI写代码
bash
1
2
3
4
5
6
注意：该值不宜过大（如超过物理内存的 5%），否则会导致可用内存减少，反而触发频繁的内存回收。

3. 调整 vm.overcommit_memory（防止内存过度分配）
vm.overcommit_memory 有 3 个取值：

0：默认值，内核根据启发式算法判断是否允许内存过度分配。
1：允许所有内存过度分配（不推荐，容易导致 OOM）。
2：禁止内存过度分配，内核仅允许分配“物理内存 + Swap 总大小”以内的内存。
服务器场景推荐设置为 2，避免应用申请过多内存导致系统崩溃：

# 临时调整
sysctl -w vm.overcommit_memory=2

# 永久调整
echo "vm.overcommit_memory=2" >> /etc/sysctl.conf
sysctl -p
AI写代码
bash
1
2
3
4
5
6
六、方法五：应用层内存优化（从“源头”减少占用）
内核和系统层面的优化是“治标”，应用层的内存优化才是“治本”。不同类型的应用有不同的优化方向，以下是常见应用的内存优化方案。

6.1 Java 应用优化（JVM 参数调整）
Java 应用的内存占用主要由 JVM 堆内存（Heap）决定，通过调整 JVM 参数可有效控制内存使用。

核心参数说明（以 JDK 11 为例）：
参数 作用说明 推荐配置（8Gi 物理内存）
-Xms 初始堆内存大小（与 -Xmx 一致，避免堆内存频繁扩容）。 -Xms4g
-Xmx 最大堆内存大小（建议不超过物理内存的 50%，预留内存给内核和其他应用）。 -Xmx4g
-XX:MetaspaceSize 元空间初始大小（元空间存储类信息，替代 JDK 7 之前的永久代）。 -XX:MetaspaceSize=256m
-XX:MaxMetaspaceSize 元空间最大大小（避免元空间无限增长）。 -XX:MaxMetaspaceSize=512m
配置方式：
在 Java 应用的启动脚本中添加参数，例如 Tomcat 的 catalina.sh：

vi $CATALINA_HOME/bin/catalina.sh

# 添加以下内容（在脚本开头）
JAVA_OPTS="-Xms4g -Xmx4g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m"
AI写代码
bash
1
2
3
4
6.2 Nginx 应用优化（减少进程内存占用）
Nginx 是多进程模型，内存占用主要由 worker_processes（工作进程数）和 worker_connections（每个进程最大连接数）决定。

优化参数：
vi /etc/nginx/nginx.conf

# 调整工作进程数（建议等于 CPU 核心数）
worker_processes auto; # auto 表示自动识别 CPU 核心数

# 调整每个进程的最大连接数（根据业务并发调整）
events {
worker_connections 1024; # 若并发高，可调整为 2048 或 4096
}

# 关闭不必要的模块（如 gzip、SSL 等，若不使用）
# 例如：若不需要 gzip 压缩，注释以下配置
# gzip on;
# gzip_types text/plain application/javascript;
AI写代码
bash

1
2
3
4
5
6
7
8
9
10
11
12
13
14
验证优化效果：
重启 Nginx 后，查看进程内存占用：

systemctl restart nginx
ps aux --sort=-%mem | grep nginx
AI写代码
bash
1
2
可见每个 Nginx worker 进程的内存占用会显著降低。

6.3 数据库应用优化（MySQL/MongoDB）
MySQL 优化（InnoDB 缓存调整）：
MySQL 的内存占用主要来自 InnoDB 缓冲池（innodb_buffer_pool_size），该缓存用于存储表数据和索引，优化该参数可减少磁盘 IO，同时控制内存占用。

vi /etc/my.cnf

# 添加以下配置（建议设置为物理内存的 50%~70%，前提是服务器仅运行 MySQL）
innodb_buffer_pool_size=16G # 若物理内存为 32Gi，设置为 16Gi

# 关闭查询缓存（MySQL 8.0 已移除，5.7 及以下版本建议关闭，避免内存浪费）
query_cache_type=0
query_cache_size=0

# 重启 MySQL 生效
systemctl restart mysqld
AI写代码
bash

1
2
3
4
5
6
7
8
9
10
11
MongoDB 优化（WiredTiger 缓存调整）：
MongoDB 默认使用 WiredTiger 存储引擎，其缓存大小由 wiredTiger.engineConfig.cacheSizeGB 控制。

vi /etc/mongod.conf

# 添加以下配置（建议设置为物理内存的 50%）
storage:
engine: wiredTiger
wiredTiger:
engineConfig:
cacheSizeGB: 16 # 若物理内存为 32Gi，设置为 16Gi

# 重启 MongoDB 生效
systemctl restart mongod
AI写代码
bash

1
2
3
4
5
6
7
8
9
10
11
七、方法六：编写“自动内存清理脚本”，实现无人值守
对于需要定期清理内存的场景（如每日凌晨业务低峰期），手动操作效率低，可编写 Shell 脚本结合 Crontab 实现自动清理。

7.1 脚本示例：自动清理缓存与 Swap
以下脚本会在“内存使用率超过 80%”或“Swap 使用率超过 50%”时，自动清理缓存和 Swap（需根据实际场景调整阈值）。

#!/bin/bash
# 自动内存清理脚本（适用于 CentOS/Ubuntu）

# 1. 定义阈值（可根据实际情况调整）
MEM_THRESHOLD=80 # 内存使用率阈值（%）
SWAP_THRESHOLD=50 # Swap 使用率阈值（%）

# 2. 获取当前内存使用率（%）
MEM_USAGE=$(free | awk '/Mem/ {printf("%.0f"), $3/$2*100}')

# 3. 获取当前 Swap 使用率（%）
SWAP_USAGE=$(free | awk '/Swap/ {if($2 != 0) printf("%.0f"), $3/$2*100; else print 0}')

# 4. 输出当前状态
echo "==================== $(date +'%Y-%m-%d %H:%M:%S') ===================="
echo "当前内存使用率：${MEM_USAGE}%（阈值：${MEM_THRESHOLD}%）"
echo "当前 Swap 使用率：${SWAP_USAGE}%（阈值：${SWAP_THRESHOLD}%）"

# 5. 若内存使用率超过阈值，清理缓存
if [ ${MEM_USAGE} -ge ${MEM_THRESHOLD} ]; then
echo "内存使用率超过阈值，开始清理缓存..."
sync && echo 3 > /proc/sys/vm/drop_caches
echo "缓存清理完成！"
else
echo "内存使用率未超过阈值，无需清理缓存。"
fi

# 6. 若 Swap 使用率超过阈值，清理 Swap（需物理内存充足）
if [ ${SWAP_USAGE} -ge ${SWAP_THRESHOLD} ]; then
FREE_MEM=$(free | awk '/Mem/ {print $4}')
USED_SWAP=$(free | awk '/Swap/ {print $3}')
# 若空闲内存 > 已用 Swap，清理 Swap
if [ ${FREE_MEM} -ge ${USED_SWAP} ]; then
echo "Swap 使用率超过阈值，开始清理 Swap..."
swapoff -a && swapon -a
echo "Swap 清理完成！"
else
echo "物理内存不足，无法清理 Swap。"
fi
else
echo "Swap 使用率未超过阈值，无需清理 Swap。"
fi

echo "======================================================================"
AI写代码
bash

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
7.2 脚本部署与定时执行
步骤 1：保存脚本并添加执行权限
# 保存脚本到 /usr/local/bin 目录
vi /usr/local/bin/auto_clean_memory.sh

# 粘贴上述脚本内容，保存退出

# 添加执行权限
chmod +x /usr/local/bin/auto_clean_memory.sh
AI写代码
bash
1
2
3
4
5
6
7
步骤 2：测试脚本是否正常运行
/usr/local/bin/auto_clean_memory.sh
AI写代码
bash
1
查看输出日志，确认脚本无报错，且逻辑符合预期。

步骤 3：配置 Crontab 定时执行
例如，设置每天凌晨 2 点执行脚本：

# 编辑 Crontab 配置
crontab -e

# 添加以下内容（日志输出到 /var/log/auto_clean_memory.log，方便排查）
0 2 * * * /usr/local/bin/auto_clean_memory.sh >> /var/log/auto_clean_memory.log 2>&1
AI写代码
bash
1
2
3
4
5
步骤 4：查看脚本执行日志
tail -f /var/log/auto_clean_memory.log
AI写代码
bash
1
八、最佳实践：内存管理的“避坑指南”与监控方案
8.1 常见误区（必须避免）
误区 1：“Free 内存少就是内存不足”
正确认知：Free 内存少但 Cache 高，说明系统缓存利用充分，无需清理；只有当 available 内存（free -h 中的 available 列，代表真正可用的内存）持续低于 10% 时，才需要关注内存问题。

误区 2：“频繁清理缓存提升性能”
正确认知：缓存的核心作用是加速文件读写，频繁清理会导致硬盘 IO 升高，反而降低系统性能。建议仅在紧急场景（如部署新应用）或缓存长期占用过高（如超过物理内存的 70%）时清理。

误区 3：“禁用 Swap 就能提升性能”
正确认知：禁用 Swap（swapoff -a 并删除 Swap 配置）会导致物理内存耗尽时直接触发 OOM，杀死关键进程（如数据库、应用服务）。即使物理内存充足，也建议保留 Swap 作为“应急储备”，仅需将 swappiness 调至 10~20 即可。

8.2 内存监控方案（实时预警）
仅靠手动查看内存状态无法及时发现问题，需搭建监控系统实现实时预警。以下是基于 Prometheus + Grafana 的监控方案（适用于企业级场景）。

步骤 1：安装 Node Exporter（采集 Linux 系统指标）
Node Exporter 是 Prometheus 的官方插件，用于采集 Linux 内存、CPU、IO 等指标：

# 下载 Node Exporter（版本可根据官网更新）
wget https://github.com/prometheus/node_exporter/releases/download/v1.6.1/node_exporter-1.6.1.linux-amd64.tar.gz

# 解压并安装
tar -zxvf node_exporter-1.6.1.linux-amd64.tar.gz
mv node_exporter-1.6.1.linux-amd64/node_exporter /usr/local/bin/

# 启动 Node Exporter（监听 9100 端口）
nohup node_exporter &
AI写代码
bash
1
2
3
4
5
6
7
8
9
步骤 2：配置 Prometheus 采集指标
编辑 Prometheus 配置文件 prometheus.yml，添加 Node Exporter 的采集任务：

scrape_configs:
- job_name: "linux_node"
static_configs:
- targets: ["192.168.1.100:9100"] # 替换为 Linux 服务器的 IP 和 Node Exporter 端口
scrape_interval: 15s # 每 15 秒采集一次
AI写代码
yaml
1
2
3
4
5
步骤 3：Grafana 导入 Linux 监控面板
登录 Grafana，点击“+” -> “Import”。
输入 Grafana 官方 Linux 监控面板 ID：8919（或搜索“Linux Node Exporter Full”）。
选择 Prometheus 数据源，点击“Import”。
步骤 4：设置内存预警规则
在 Grafana 中添加预警（Alert），例如：

当“内存使用率（used%）”持续 5 分钟超过 90% 时，发送邮件告警。
当“Swap 使用率”持续 5 分钟超过 60% 时，发送短信告警。
九、总结：Linux 内存管理的“核心原则”
Linux 内存释放不是“一劳永逸”的操作，而是“系统优化 + 应用优化 + 监控预警”的综合过程。核心原则如下：

优先利用缓存，而非频繁清理：缓存是 Linux 提升性能的关键，只有在内存真正紧张时才清理。
Swap 是“应急储备”，而非“常规内存”：通过调整 swappiness 减少 Swap 使用，避免频繁换入换出导致卡顿。
进程是内存占用的“源头”：定期排查高内存进程和内存泄漏，从应用层优化内存使用（如 JVM 调优、数据库缓存调整）。
自动化与监控是“长效保障”：通过脚本实现自动清理，结合 Prometheus + Grafana 实时监控，提前发现并解决问题。
————————————————
版权声明：本文为CSDN博主「xl.liu」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/xinlinliu/article/details/152899039