内存泄漏定位清理脚本释放服务器内存资源

知识分享

2026-07-20 11:40

16 阅读

先搞懂：什么情况算内存泄漏，为什么需要清理脚本

服务器内存被占满，不一定都是泄漏。
正常应用也会缓存文件、分配内存后释放不及时。内存泄漏指进程申请内存后，不再使用却未归还，导致可用内存逐渐减少，最终影响业务。
常见现象：free -m 显示可用内存持续下降，重启进程后内存立刻恢复。

本文适合 Linux 服务器（CentOS / Ubuntu / Debian 均可），使用命令行或宝塔面板操作。
你将学会：快速定位泄漏进程 → 编写一个安全的清理脚本 → 定期自动释放被占用的内存资源。

第一步：确认内存状况，找到疑似泄漏的进程

先用两个命令摸清服务器内存状态：

# 查看内存总体情况（单位 MB）
free -m
# 按内存占用排序显示进程（前 10 个）
ps aux --sort=-%mem | head -11

关注 free -m 输出的 available 列，如果长期低于总内存 10% 且不断下降，就要排查。ps 列表中 %MEM 最高的进程是首要怀疑对象。

注意：MySQL、Java 应用（如 Tomcat）本身会预申请大量内存，这不一定是泄漏，要结合进程启动后的持续增长来判断。

如果你用了宝塔面板，可以在“监控” → “进程”里勾选“内存占用”排序，图形化查看变化。

第二步：深入定位泄漏进程（或用工具辅助）

如果觉得手动监控麻烦，推荐用 smem 工具，它能更准确显示进程实际物理内存（USS/PSS）：

# 安装 smem（CentOS 需先安装 EPEL）
yum install epel-release -y && yum install smem -y
# 或 Ubuntu/Debian
apt update && apt install smem -y

# 按物理内存占用排序显示
smem -s uss -r | head -10

USS 是进程独享物理内存，数值持续增长的进程几乎可以确定为泄漏。
记录下该进程的 PID 和名称。

避坑：别一看到高内存就 kill，先确认是业务进程还是缓存进程（如 java、python、node 这类常驻程序），缓存进程重启会影响在线用户。

第三步：编写内存清理脚本，定期释放资源

脚本分两个部分：一是清理系统缓存（不影响业务），二是终止确认泄漏的进程并自动重启。务必先备份脚本中要重启的服务信息。

新建脚本文件 /opt/clean_mem.sh：

#!/bin/bash
# 内存清理脚本 - 安全版
# 使用场景：服务器可用内存持续偏低，已知泄漏进程且可安全重启

LOG_FILE="/var/log/mem_clean.log"
echo "=== $(date) ===" >> $LOG_FILE

# 1. 清理系统缓存（PageCache、dentries、inodes）
echo 3 > /proc/sys/vm/drop_caches

echo "系统缓存已清理" >> $LOG_FILE

# 2. 定义已知泄漏进程的 PID 或进程名（请根据实际修改）
LEAK_PID="1234"   # 替换为你定位到的 PID
LEAK_NAME="myservice"  # 替换为进程名，用于重启

if [ -d /proc/$LEAK_PID ]; then
    kill $LEAK_PID
    sleep 2
    # 如果进程未退出，强制终止
    kill -9 $LEAK_PID 2>/dev/null
    echo "已终止 PID $LEAK_PID ($LEAK_NAME)" >> $LOG_FILE
    # 这里添加重启命令，例如 systemctl restart myservice
    systemctl restart $LEAK_NAME 2>/dev/null || /etc/init.d/$LEAK_NAME restart
    echo "已重启 $LEAK_NAME" >> $LOG_FILE
fi

# 3. 记录清理后内存
echo "清理后内存状态：" >> $LOG_FILE
free -m >> $LOG_FILE

赋予执行权限并测试：

chmod +x /opt/clean_mem.sh
/opt/clean_mem.sh
cat /var/log/mem_clean.log

注意：脚本中的 LEAK_PID 和 LEAK_NAME 必须替换为你自己找到的进程。直接执行现成脚本可能导致正常服务被误杀。

设置定时任务自动运行

crontab -e

添加一行（每天凌晨 3 点执行）：

0 3 * * * /opt/clean_mem.sh

保存后可用 crontab -l 验证。
如果不需要自动清理，也可以手动执行。

避坑指南：清理脚本不会伤害服务器吗？

清理系统缓存（drop_caches） 是 Linux 内核的安全功能，释放的是文件缓存，不会影响正在运行的程序。执行后业务第一次读写可能稍慢，但内存会被回收给应用程序，利大于弊。
重启泄漏进程 会让该服务短暂中断。如果是数据库或线上服务，请务必在业务低峰期操作，并提前通知相关方。
不要同时杀死多个怀疑进程：一次只处理一个，观察内存是否回升。
如果找不到进程持续增长，但内存确实被吃光，可能是系统 slab 缓存泄漏（例如 dentry、inode 缓存），这时需要更深入排查，脚本中的 drop_caches 可以缓解，但治标不治本，建议更新内核版本。

效果验证：怎么确认内存资源释放成功？

执行脚本后，用以下步骤检查：

# 查看内存变化
free -m
# 查看日志
cat /var/log/mem_clean.log
# 持续观察一段时间（比如 1 小时），确认可用内存不再快速下降
watch -n 60 free -m

同时在宝塔面板资源监控中查看内存曲线：如果之前持续下降，清理后曲线趋于平稳或回升，说明脚本生效。
如果仍然很快被占满，说明泄漏进程并未彻底终止或存在多个泄漏点，重复定位步骤。

常见问题

Q：清理脚本执行后，网站立刻变慢了？
A：drop_caches 清除了文件缓存，首次访问静态资源时需要重新读盘，1-2 分钟后缓存重建完毕速度恢复。如果持续慢，检查进程是否被误杀。

Q：内存泄漏定位后，一定要用脚本清理吗？
A：最好先更新程序版本或修复代码，脚本只是应急手段。长期依赖脚本掩盖问题可能会隐藏更深的风险。

Q：用宝塔面板的“释放内存”功能可以吗？
A：宝塔的“释放内存”本质也是执行 sync && echo 3 > /proc/sys/vm/drop_caches，只能清理缓存，无法定位并处理泄漏进程。本文的脚本更全面。

如果你正被服务器内存泄漏困扰，建议先按本文步骤完整执行一次，再根据你的环境微调 PID 和进程名。
遇到异常时优先回看避坑和高频问题部分。

ArgoCD容器持续交付AI中转服务流水线

网站收录诊断全流程排查抓取失败根源：网站收录诊断全流程