半夜收到告警，内存使用率冲到 96%，SSH 上去敲 free 只剩下几十兆可用，网站开始变慢。这种时候很多人的第一反应是重启服务器，重启的确能让数字好看，但几个小时后又满。网站内存占用高怎么办，正确的顺序是先看清楚是谁在吃，再决定是清缓存、调限制还是改代码。
一、先看总量、可用量和缓存，别被数字吓到
free 的输出里，Mem 那一行有 total、used、free、buff/cache、available 几个数字。真正该看的是 available，它才是能马上拿来用的内存。buff/cache 高是好事，说明系统拿空闲内存缓存了磁盘数据，这部分随时可回收，不算问题。很多人一看 free 只剩几十兆就紧张，其实 available 还有几百兆，属于正常。下面这条命令把关键几项一次列出来，跑完重点看 MemAvailable 和 SwapFree，前者常年低于总量的百分之十就要警惕。
# 查看内存总览，重点看 MemAvailable 和交换分区使用
free -h
grep -E 'MemTotal|MemAvailable|SwapTotal|SwapFree' /proc/meminfo
二、用 top 和 ps 找出吃内存的进程
确认内存真的紧张后，下一步是找出大户。top 打开后按大写 M 可以按内存占用排序，看 RES 那一列，单位是 KB；如果想在脚本里做，就用 ps 按 rss 降序取前十。要改的是排序字段，内存降序用 -rss，CPU 降序用 -pcpu。跑完看前十名，常见的吃内存大户有 php-fpm 的一堆子进程、MySQL、Redis、Java 应用，还有一种要特别留意的——不认识的进程名且 CPU 长期跑满，那可能是被挂马后塞进来的挖矿程序。
# 按内存占用排序取前十
ps aux --sort=-rss | head -10
# 只看某一类进程合计占了多少内存
ps -C php-fpm -o rss= | awk '{s+=$1} END {print s/1024 " MB"}'
三、分清三种情况：正常缓存、配置过大、内存泄漏
找到大户之后，别急着下结论。三种情况要分开看。配置过大，指应用自身参数设得太高，比如 php-fpm 的 pm.max_children 设成 200，每个子进程几十兆，加起来就是几个 G；内存泄漏，指进程的 RSS 持续单边上涨，重启后回落，过一两天又爬到同样高度；正常高峰，指白天高、夜里回落，曲线有节奏。判断方法很简单：每天固定时间记录一次关键进程的内存占用，连续记一周，看曲线形态。下面这段记录脚本加到定时任务里即可。
#!/bin/bash
# 每天记录一次关键进程的内存占用，用于判断是否存在内存泄漏
for p in php-fpm mysqld nginx; do
rss=$(ps -C "$p" -o rss= 2>/dev/null | awk '{s+=$1} END {print int(s/1024)}')
echo "$(date +%F) $p ${rss:-0} MB" >> /var/log/mem_watch.log
done
同一进程的数值一天比一天高、始终没有回落，基本可以确认是内存泄漏，得回去查代码里有没有未关闭的连接、未释放的对象或只增不减的全局数组。数值稳定在区间内波动，那就是配置问题，调参数即可。
四、释放策略：三种手段，按场景选
第一种是释放缓存，即清掉系统可回收的 buff/cache。执行前先 sync 把脏页写回磁盘，再写入 drop_caches，能立刻腾出空间。要注意这会清掉文件缓存，之后一段时间磁盘读会变慢，所以只在排查和应急时用一次，别写进定时任务天天跑。第二种是调配置上限，把 php-fpm 的 pm.max_children、MySQL 的缓冲池、Redis 的 maxmemory 按实际内存调小，给系统留出余量。第三种是加自动回收，用 systemd 给服务设内存上限，超了自动重启，避免某个进程把整机拖死。改完等一个业务高峰验证，用 free -h 看 available 是否稳定保持在几百兆以上，服务重启次数是否下降。
# 应急释放系统缓存：先 sync 再 drop_caches
sync
echo 3 > /proc/sys/vm/drop_caches
# 对照前后变化
free -h
内存问题的处理思路是观测、定位、验证，别一上来就重启。把每天的记录留着，下次再告警，看一眼曲线就知道是老毛病还是新情况，处理起来快得多。
相关阅读：
《内存天天跑满、服务被系统杀掉？先找出是谁在吃内存》
《Linux服务器常用命令速查：运维高频操作一页搞定》
《数据库越来越慢拖垮整站？从慢查询日志开始查》
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
