服务器运行一段时间后，监控面板可能显示内存使用率超过 80%，甚至接近满载。此时网站仍然可以正常访问，CPU 占用也不高，是否说明服务器需要升级内存？
判断 Linux 内存是否不足，需要同时观察可用内存、内存压力、进程占用和业务表现。只看一个使用率数字，容易把正常缓存误认为故障，也可能忽略容器内部的资源限制。
下面按照实际排查顺序，介绍常用命令及对应的判断方法。
一、先看 available，不要只看 free
在服务器终端执行：
free -h重点关注以下字段：
| 字段 | 含义 | 如何理解 |
|---|---|---|
total | 系统可用的总内存 | 用来了解内存规模 |
used | 已使用或不可用内存 | 具体计算口径可能随工具版本变化 |
free | 当前完全空闲的内存 | 数值较小不一定异常 |
buff/cache | 内核缓冲和缓存占用 | 部分可以回收，并非全部能够立即释放 |
available | 无需换页即可供新应用使用的内存估计值 | 比单独看 free 更适合判断整体余量 |
Linux 会利用内存缓存文件数据，以减少重复读取磁盘的开销。读取过大量文件后，缓存增加、空闲内存减少，是可能出现的正常现象。
例如，假设一台服务器的 free 只有 200MiB，而 available 仍有 3GiB，就不能说它“只剩 200MiB 内存可用”。
不过，available 只是系统层面的估计值。是否存在实际压力，还要继续检查换页、进程及容器限制。
二、Swap 有占用，是否说明内存不足？
查看短时间内的运行情况：
vmstat 1 6该命令输出六次报告，相邻报告间隔一秒。判断当前活动时，主要查看后续采样；第一行的交换和 CPU 等速率数据反映启动以来的平均情况，内存、进程字段则是即时值。
重点关注：
swpd：已经使用的 Swap 容量。si：每秒从 Swap 换入内存的数据量。so：每秒从内存换出到 Swap 的数据量。
Swap 已使用多少，与系统当前是否频繁换页，是两件不同的事。
部分不活跃的数据可能早已被换出，之后即使物理内存压力缓解，Swap 占用也不一定立即归零。因此，看到 Swap 有数据，不必马上清空。
如果 available 持续偏低，同时 si、so 在多个采样中持续活跃，并伴随接口变慢、任务耗时增加，就需要进一步排查。
没有启用 Swap 的服务器，si 和 so 可以始终为零。这也不能证明内存充足。
补充查看内存压力
支持 PSI 的 Linux 系统可以执行：
cat /proc/pressure/memory其中：
some：至少部分任务因内存资源而停顿的时间占比。full：所有非空闲任务同时因内存资源而停顿的时间占比。avg10、avg60、avg300：分别对应最近 10 秒、60 秒和 300 秒的平均占比。
这些指标反映的是任务停顿，而非内存使用百分比。应结合业务正常时期的基线观察；持续升高并伴随响应变慢，比单次内存使用率更值得关注。
如果文件不存在，说明当前环境未提供该接口，可以继续使用其他指标排查。
三、找出主要占用内存的进程
按常驻内存从高到低排列进程：
ps -eo pid,ppid,user,comm,rss,%mem --sort=-rss | head -n 16这会显示表头及内存占用靠前的 15 个进程。
| 字段 | 含义 |
|---|---|
PID | 进程编号 |
PPID | 父进程编号 |
USER | 运行用户 |
COMMAND | 进程名称 |
RSS | 常驻物理内存大小，单位为 KiB |
%MEM | RSS 相对于物理内存的比例 |
如果某个进程的 RSS 为 524288，约等于 512MiB。
排查时，既要留意单个大进程，也要关注同类进程的数量。例如，单个工作进程占用不高，但同时运行几十个，总体内存需求仍可能很大。
排名靠前，不代表内存泄漏
数据库缓存、应用缓存和程序预热，都可能使进程内存逐渐增加。
判断泄漏，需要观察在相近业务负载下，内存是否持续增长、能否稳定下来，以及增长是否与请求量或任务积压有关。一次 ps 输出无法直接证明泄漏。
此外，共享内存页可能被计入多个进程的 RSS，不能简单把所有 RSS 相加，当作系统总占用。
需要进一步分析某个进程时，可查看内核提供的汇总数据：
sudo awk '/^(Rss|Pss|Private_Clean|Private_Dirty|Swap):/ {print}' \
/proc/1234/smaps_rollup将 1234 替换为实际 PID。Pss 会按共享比例分摊内存，更适合辅助分析共享映射较多的程序。该文件是否可读，取决于内核支持和访问权限。
四、使用 Docker，还要检查容器自己的限制
宿主机还有空闲内存，并不代表容器一定有足够的可用额度。
在运行 Docker 的服务器上执行：
docker stats --no-stream关注 MEM USAGE / LIMIT 一列，查看各容器的使用量和可用上限。
例如，一台宿主机仍有较多内存余量，但某个容器被限制为 512MiB，它仍然可能因触及自身限制而发生内存分配失败或 OOM。
还需要注意两种统计差异：
- Linux 上的
docker stats会按其规则扣除部分文件缓存。 - 容器内部的
free输出，不一定准确反映容器自身的内存额度。
因此，不要直接将宿主机 free、容器内部 free 和 docker stats 的数字混在一起比较。
如果容器确实触及限制，应先检查应用是否需要更多内存、是否存在异常增长，再结合宿主机余量调整。直接取消全部限制，可能让单个服务影响其他业务。
五、程序突然退出，检查是否发生 OOM
对于使用 systemd 的服务器，可查看本次启动中最近 24 小时的相关内核日志：
sudo journalctl -k -b 0 --since "24 hours ago" --no-pager \
| grep -Ei 'out of memory|oom-kill|killed process'如果存在匹配记录，应结合时间、进程名称和上下文判断：
- 是整个系统的内存压力，还是某个 cgroup 的限制？
- 被终止的进程属于哪个业务？
- 事发时是否存在访问高峰、批处理任务或异常并发？
被 OOM 机制终止的进程，不一定就是唯一造成内存压力的程序，不能仅凭进程名称下结论。
如果服务器已经重启，需要另外检查重启前保存的日志。上述命令没有输出，也只代表当前查询范围内没有匹配记录；日志缺失、应用主动退出及其他进程管理机制仍需分别排查。
六、确认原因后，如何处理？
可以根据观察结果选择对应方向：
| 观察结果 | 处理方向 |
|---|---|
| 缓存较多，但可用内存充足、业务正常 | 持续观察，无需为了降低数字而清缓存 |
| 工作进程或并发任务过多 | 检查并发配置、任务积压和单任务内存需求 |
| 单个程序在相近负载下持续增长 | 排查缓存策略、程序缺陷或内存泄漏 |
| 容器频繁触及自身限制 | 检查应用需求及容器额度，结合宿主机容量调整 |
| 高峰期持续出现压力、换页或 OOM | 优化负载分配，并评估扩容或拆分服务 |
如果进程列表无法解释内存占用，还可以进一步检查共享内存、tmpfs 和内核 Slab。进程 RSS 并不涵盖所有系统内存用途。
不建议定时强制清理缓存
网上常见的 drop_caches 操作，主要用于丢弃可回收缓存，不能解决应用内存泄漏，也不能替代容量规划。
缓存被清理后，后续访问可能需要重新读取磁盘、重新建立缓存，增加 I/O 和 CPU 开销。将其设置为频繁执行的定时任务，可能使网站和数据库出现性能波动。
扩容前，先记录业务高峰
建议记录高峰期间的可用内存、主要进程占用、内存压力及业务响应时间，并保留一段时间的趋势。
如果正常业务需求已经持续超过现有资源，增加内存或拆分服务才有明确依据。如果问题来自异常并发或程序持续增长，扩容可能只能延后故障，还需要处理对应原因。
