VPS执行free -h后看到used很高，不能直接得出“内存快耗尽”的结论。Linux会主动把空闲内存用于文件缓存，以减少磁盘读取；业务需要时，部分缓存可以被回收。真正需要关注的是available是否持续下降、是否频繁换页、内存压力是否升高，以及进程有没有因内存限制被回收或杀死。
free、available和buff/cache分别回答什么
free -h
grep -E 'MemTotal|MemFree|MemAvailable|Buffers|Cached|SwapTotal|SwapFree' /proc/meminfofree表示完全未使用的内存，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 --showvmstat中的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记录。缓存高但业务无压力通常无需处理；持续回收、换页和服务失败才是优化或扩容的证据。
