### [VPS内存显示快满了要紧吗？先看available、缓存、Swap和内存压力](https://www.jiyueip.com/article/13488)

**Published:** 2026-07-30T07:47:09

**Author:** 斑斓助理

**Excerpt:** Linux VPS里used很高不一定表示内存不足，文件缓存可以按需回收。判断是否需要扩容，应结合available、Swap换入换出、PSI、cgroup限制、OOM记录和业务延迟。

VPS执行`free -h`后看到used很高，不能直接得出“内存快耗尽”的结论。Linux会主动把空闲内存用于文件缓存，以减少磁盘读取；业务需要时，部分缓存可以被回收。真正需要关注的是`available`是否持续下降、是否频繁换页、内存压力是否升高，以及进程有没有因内存限制被回收或杀死。

## free、available和buff/cache分别回答什么

```
free -h
grep -E 'MemTotal|MemFree|MemAvailable|Buffers|Cached|SwapTotal|SwapFree' /proc/meminfo
```

`free`表示完全未使用的内存，Linux正常运行时它可以很小。`buff/cache`包含用于内核和文件访问的缓存，并非全部“被应用永久占住”。`available`是系统在不发生明显换页的情况下，可供新应用使用的估算值，通常比只看free更有判断价值。

不过available也不是承诺值。内核版本、工作负载和容器限制都会影响解释，短时采样不能代替趋势。应与同一实例平时的业务时段比较。

## 四种“内存很高”需要不同处理

| 现象  | 更可能的含义 | 下一步 |
| --- | --- | --- |
| used高，available仍充足，业务正常 | 文件缓存或正常工作集 | 继续观察趋势，不急着清缓存 |
| available持续下降，Swap换入换出增加 | 活跃工作集超过物理内存 | 定位进程增长、并发与内存泄漏 |
| 宿主机有余量，容器内频繁OOM | cgroup内存上限或容器配置 | 检查memory.current、memory.max和memory.events |
| 内存看似正常，业务仍停顿 | 回收、换页或I/O压力造成延迟 | 查看PSI、vmstat和磁盘延迟 |

“占用率达到多少必须扩容”没有通用阈值。数据库、Java服务、文件缓存和批处理的内存形态不同，扩容决策应以持续压力和业务症状为依据。

## Swap用了不等于系统正在缺内存

Linux可能把长期不活跃的页面移入Swap，即使后来物理内存已经有空闲，Swap占用也不会立即归零。更重要的是当前是否持续发生换入换出：

```
vmstat 1 5
swapon --show
```

`vmstat`中的`si`和`so`用于观察换入、换出活动。偶尔出现与持续高频不同；若它们在业务变慢时连续出现，还伴随磁盘等待，就说明内存压力已经影响响应。

不要为了让监控数字好看就随意关闭Swap。没有足够物理内存时，关闭过程可能加剧压力；是否调整Swap应结合工作集、磁盘性能、OOM风险和服务恢复要求。

## 怎样找到真正占内存的进程

```
ps -eo pid,ppid,comm,rss,vsz --sort=-rss | head
systemd-cgtop
```

RSS表示进程当前驻留在物理内存中的页面，但共享库可能被多个进程重复显示，简单相加可能高估。VSZ包含尚未实际驻留的虚拟地址空间，也不能直接当作物理内存消耗。

若某个进程的RSS随时间单向增长，应对照请求量、缓存项、线程数、连接池和应用自身指标。一次排序只能说明当时谁占得多，不能证明内存泄漏；至少需要同一业务负载下的连续样本。

## 容器里的可用内存为什么和VPS整机不同

Docker、Kubernetes或systemd服务可能受cgroup内存限制。即使`free -h`显示整机还有空间，某个容器达到自己的上限仍可能回收或OOM。在使用统一cgroup层级的系统中，可检查：

```
cat /sys/fs/cgroup/memory.current
cat /sys/fs/cgroup/memory.max
cat /sys/fs/cgroup/memory.events
```

实际路径会随容器和systemd单元层级变化。`memory.events`中的事件变化能帮助判断是否触发高水位、达到上限或发生OOM；不要只根据容器面板的一次百分比修改配额。

## 用内存PSI判断业务是否真的在等

```
cat /proc/pressure/memory
```

PSI记录任务因内存回收或资源压力而停顿的情况。将其与接口延迟、队列长度、`vmstat`换页和磁盘I/O放在同一时间轴，更容易判断内存压力是否影响业务。某个瞬时数值不能单独证明需要扩容，持续趋势和同机基线更重要。

## 为什么不应把“清理缓存”当成日常修复

可回收缓存本来就是Linux利用内存提升性能的机制。强行清空后，后续请求可能重新读取磁盘，带来I/O尖峰和响应抖动，却没有解决进程工作集过大、内存泄漏或容器限额问题。

除非在明确的测试或维护场景中需要控制缓存变量，否则应让内核管理缓存。生产故障先保存`free`、`/proc/meminfo`、进程RSS、PSI、换页和OOM日志，再决定降低并发、修复应用、调整配额还是扩容。

## 什么时候扩容更有依据

-   相同负载下available持续降低，且无法在任务结束后恢复；
-   Swap换入换出与磁盘等待长期伴随业务延迟；
-   经过应用缓存、并发和进程泄漏治理后，工作集仍稳定超过现有容量；
-   cgroup上限是明确瓶颈，调整后整机容量也无法承载；
-   内核或cgroup OOM事件已被日志证实，并影响关键服务。

扩容前记录峰值时段、业务吞吐和故障指标，扩容后用同一口径复测。这样才能判断增加内存是否真正减少换页、停顿和失败，而不只是让used百分比变小。

## 结论

VPS内存是否紧张，不能只看used或free。先看available和趋势，再检查Swap换入换出、进程工作集、cgroup事件、内存PSI与OOM记录。缓存高但业务无压力通常无需处理；持续回收、换页和服务失败才是优化或扩容的证据。

**Tags:** Linux服务器, VPS, VPS性能, VPS监控, 网络故障排查

**Categories:** 行业洞察

---