直接答案：不要只看 used，也不要按网站数量套用 2G、4G、8G。应拆出操作系统常驻、Web/应用进程、数据库与缓存、单请求或单任务增量、发布和备份峰值，再以 MemAvailable、OOM、换页速率和业务延迟验证。Linux 会把空闲内存用于缓存，used 高并不等于缺内存。
本文于 2026 年 9 月按公开技术文档重新核对。文中的公式用于建立可复测预算，不是厂商性能或价格承诺；实例代际、线路、计费和功能会变化，最终应以当前产品页、合同、控制台和自己的原始测试为准。
先把问题变成一张证据表
| 对象/信号 | 含义或适用场景 | 应核对的证据 | 决策边界 |
|---|---|---|---|
| 2G | 单个轻量静态/低流量动态站 | 系统与数据库需严格限额 | 发布、备份并发易触顶 |
| 4G | 中小动态站或少量容器 | 可分配明确数据库缓存 | 仍需测插件/队列峰值 |
| 8G | 较大工作集、多服务或Java | 可保留更多页缓存 | 不能代替泄漏治理 |
| Swap少量使用 | 冷页换出或短时缓冲 | 观察si/so与延迟 | 不等于必须清空 |
| 持续大量换页 | 工作集超过物理内存 | 找增长进程和峰值 | 应限额、修复或扩容 |
这张表的作用是把“感觉够用”“听说更快”改成可以复核的条件。同一规格在不同镜像、地区、底层代际和业务模型中可能得到不同结果。对比时必须固定应用版本、数据集、测试点和时间窗口；缺少这些条件的跑分或报价，只能当线索，不能直接用于采购。
核心计算与判断模型
建议内存 = 系统与守护进程常驻 + 应用稳定工作集 + 数据库/缓存预算 + 峰值并发增量 + 维护任务峰值 + 安全余量。各项必须来自分时采样；若任务不会同时发生，可用受控调度避免把所有最大值简单相加。
计算后还要做反向校验：如果预算推导出的配置与真实监控差异很大，先检查单位、采样周期、缓存命中、突发任务和统计口径。不要为了让公式符合预期而删掉异常样本；异常样本往往正是容量、计费或故障风险所在。
建议同时保留“正常日、业务高峰、发布/备份日”三条基线。平均值用于成本预测，峰值和尾延迟用于稳定性判断，故障演练用于恢复能力判断。三类证据回答不同问题，不能互相替代。
可执行的六步流程
第1步：先留证据，再作决定
至少采集七天 free、MemAvailable、swap、major fault、OOM 事件和各进程 RSS/PSS；覆盖发布、备份、缓存预热、流量高峰和计划任务。
这一步要保留时间、测试条件、原始结果和操作者。若结果与预期不同，先回到上一项确认变量，不要同时改规格、系统、缓存和网络，否则即使现象消失，也无法知道真正起效的是哪一项。
第2步：先留证据，再作决定
给数据库、Redis、PHP-FPM、JVM、Node 和容器分别设预算。配置上限相加不得挤掉系统、文件缓存和故障恢复空间，容器 limit 也不能高于宿主机真实能力。
这一步要保留时间、测试条件、原始结果和操作者。若结果与预期不同，先回到上一项确认变量，不要同时改规格、系统、缓存和网络，否则即使现象消失，也无法知道真正起效的是哪一项。
第3步：先留证据，再作决定
用并发阶梯测试记录每增加一组并发的内存增量，区分一次性缓存预热和持续增长；持续增长且请求结束后不回落，才更像泄漏。
这一步要保留时间、测试条件、原始结果和操作者。若结果与预期不同，先回到上一项确认变量，不要同时改规格、系统、缓存和网络，否则即使现象消失，也无法知道真正起效的是哪一项。
第4步：先留证据，再作决定
MySQL 要把 buffer pool、连接缓冲、排序/临时表等分开。max_connections 乘每连接潜在内存只是风险上界，不应当作日常实际占用。
这一步要保留时间、测试条件、原始结果和操作者。若结果与预期不同，先回到上一项确认变量，不要同时改规格、系统、缓存和网络，否则即使现象消失，也无法知道真正起效的是哪一项。
第5步：先留证据，再作决定
Java 应同时计算堆、Metaspace、线程栈、直接内存和系统余量；只把 -Xmx 设成机器内存的固定百分比，可能让非堆或内核在高峰被挤压。
这一步要保留时间、测试条件、原始结果和操作者。若结果与预期不同，先回到上一项确认变量，不要同时改规格、系统、缓存和网络，否则即使现象消失，也无法知道真正起效的是哪一项。
第6步：先留证据，再作决定
先限并发、调缓存或拆任务，再决定升配。若 OOM 已影响写入，先保护数据和降低流量，不要反复重启让服务进入崩溃循环。
这一步要保留时间、测试条件、原始结果和操作者。若结果与预期不同，先回到上一项确认变量，不要同时改规格、系统、缓存和网络，否则即使现象消失，也无法知道真正起效的是哪一项。
五个最容易造成误判的做法
- 把buff/cache全部当作可删除垃圾
- 为了看起来空闲而频繁drop_caches
- 依赖Swap承载稳定工作集
- 把所有进程配置上限同时设满
- 只在空闲时截图后就降配
这些做法共同的问题是缺少可比较条件。正确的纠偏方式不是再换一个“推荐配置”，而是把输入、阈值、失败现象和回滚条件写进记录。涉及删除数据、改防火墙、重装、扩缩容或切换 DNS 时，必须先有备份和可用的回滚入口。
上线、变更与回滚边界
先在隔离环境或小流量上验证，再逐步扩大。变更前保存配置、账单截图、监控基线和关键数据备份；变更中只改一个主要变量；变更后使用相同测试重跑。若核心业务写入失败、错误率持续上升、尾延迟越过停止阈值、数据校验不一致或管理员入口失效，应立即停止扩量并按预案回滚。
回滚不是简单恢复一个控制台选项。还要检查期间产生的新订单、表单、上传或数据库写入，明确如何合并，避免回到旧环境后丢失新数据。只读站与持续交易站的回滚难度完全不同，方案必须按业务写入特征设计。
验收清单
- [ ] 七天峰值样本完整
- [ ] 无新增OOM
- [ ] MemAvailable有余量
- [ ] si/so不持续升高
- [ ] p95延迟稳定
- [ ] 维护任务可完成
- [ ] 服务重启后不抖动
- [ ] 各组件预算有记录
至少跨过一次真实高峰或等价的受控测试，并由另一位维护者按记录复现关键结果。只完成“页面能打开”不算验收；必须能解释资源、网络、费用、恢复和安全边界。验收失败时，把具体指标和时间写入问题单，而不是用“偶尔慢”“可能线路问题”结束调查。
相关站内资料与产品入口
可结合内存不足与 OOM 排查、监控告警指南、一个服务器放几个网站继续核对。需要建立隔离测试环境时，可查看美国轻量云和美国弹性云服务器的实时规格、库存及计费；本文不写死价格，也不把某个当前套餐描述成对所有业务都合适。
常见问题
Linux内存90%是不是要升级？
不一定。先看 MemAvailable、换页、OOM 和业务延迟。文件缓存可在需要时回收，单独的 used 百分比不能判断容量不足。
2G能运行WordPress吗？
精简环境和低流量可以，但主题、插件、PHP并发、数据库和备份会改变峰值。应通过真实页面与后台操作测工作集，不把能启动当成能稳定运行。
Swap设多大合适？
没有通用倍数。它可为冷页和短时峰值提供缓冲，但磁盘慢于内存。应按休眠需求、磁盘类型、延迟目标和故障策略设定并监控换页。
内存泄漏只能重启解决吗？
重启可临时恢复，但会丢失证据。先记录进程、堆、连接和增长曲线，定位版本或请求类型；修复后用相同负载验证不再单向增长。
加内存后为什么网站仍慢？
瓶颈可能在CPU、磁盘、锁、网络或外部接口。若无换页和OOM且工作集已被缓存覆盖，继续加内存未必改善TTFB。