linux脚本无法真正释放被程序占用的内存，只能通过清理缓存、重启泄漏进程或调优内核参数来缓解压力；关键在于降低used内存占比，避免oom killer误杀关键进程。
Linux 脚本无法真正“释放”已被程序占用的内存（除非程序主动释放或被终止），但可以通过清理缓存、重启高内存进程或触发内核回收机制来缓解内存压力。关键不是“释放内存”，而是降低 used 内存占比，避免 OOM Killer 杀死关键进程。
监控内存并触发清理缓存
Linux 会自动利用空闲内存做 page cache、buffer 等，这部分（Cached / Buffers）在需要时可被快速回收。当可用内存低于阈值时，可手动触发清理：
- 运行
sync && echo 3 > /proc/sys/vm/drop_caches清空 pagecache、dentries 和 inodes（仅影响缓存，不杀进程） - 该操作需 root 权限，且效果取决于当前缓存占用量；若
free -h中available已足够，无需执行 - 建议配合
MemAvailable（而非free）判断真实可用内存，更准确反映系统余量
识别并重启/终止内存泄漏进程
持续增长的 RSS 内存（如 Java、Node.js 应用未释放对象）才是真问题。脚本可定期检测异常进程：
- 用
ps aux --sort=-%mem | head -n 11查看 Top 10 内存占用进程 - 结合
awk '{if($6>2000000) print $2,$11}' /proc/*/stat 2>/dev/null找 RSS > 2GB 的进程 PID - 对已知易泄漏的服务（如某 Python 后台），可设定 RSS 阈值（如 1.5GB），超限后
systemctl restart xxx或kill -9 PID
配置内核参数提前干预
靠脚本轮询是补救，更稳妥的是让内核更积极回收：
- 调低
vm.swappiness（默认 60）→ 改为 10，减少倾向使用 swap，优先回收 cache - 增大
vm.vfs_cache_pressure（默认 100）→ 设为 150，加快 dentry/inode 回收 - 启用
vm.oom_kill_allocating_task=0（默认），确保 OOM 时按 badness 分数选最该杀的进程，而非直接杀申请内存者
用 systemd 服务实现自动守护
把监控逻辑封装为 systemd service，比 crontab 更可靠（支持依赖、日志、重启策略）：
- 写一个
/usr/local/bin/check-mem.sh，含内存检查、drop_caches、进程处理逻辑 - 创建
/etc/systemd/system/mem-guard.service，设Type=oneshot+ExecStart=/usr/local/bin/check-mem.sh - 配
mem-guard.timer每 5 分钟触发一次，启用并启动 timer 即可 - 日志用
journalctl -u mem-guard查看，便于调试阈值是否合理
不复杂但容易忽略：先确认是缓存堆积还是真实泄漏，再决定用 drop_caches 还是杀进程；频繁触发说明应用层需优化，脚本只是临时兜底。
