内存型规格是什么
内存型规格的 vCPU 与内存配比约为 1:8，面向缓存与内存数据库这类对内存容量敏感的业务，例如 Redis、内存数据库与实时计算。部分厂商还提供比例更高的内存扩展型，适合几乎纯内存的工作负载。
基本信息
| 比例 | vCPU 与内存约 1:8，例如 4 核 32G |
|---|---|
| 场景 | 缓存、内存数据库、时序与实时计算、大页内存应用 |
| 扩展型 | 比例可达 1:16，适合纯内存工作负载 |
| 三厂命名 | 内存型 r 系列 / 内存型 M 系列 / 内存型 m 系列 |
| 选型依据 | 内存水位、OOM 记录与 swap 使用情况 |
| 配额 | 大内存规格数量有限，扩容前先确认配额 |
现象与结论
| 现象 | 可能原因 | 动作 |
|---|---|---|
| 频繁 OOM | 真实内存不足或存在泄漏 | 先修泄漏，再评估升配 |
| 内存水位高但不用 swap | 请求量持续增长 | 评估升配或扩副本 |
| 内存缓慢持续增长 | 应用内存泄漏 | 定位代码问题 |
| 单实例内存到顶 | 缓存数据量超预期 | 考虑分片或改集群 |
本机内存占用排查
本机内存占用排查
ps aux --sort=-%mem | head -n 11 # 找出内存占用前几名
free -m # 总内存、已用与 swap
dmesg | grep -i oom | tail # 是否有 OOM 记录典型使用场景
- 缓存服务内存水位长期偏高，需要按真实占用选规格
- 内存数据库需要大内存与稳定延迟，优先内存型
- 实时计算任务需要把中间状态放在内存里
- 应用频繁被 OOM 杀掉，先定位原因再决定是否升配
升级内存前先看 swap 使用与 OOM 记录：频繁 OOM 才是真缺内存，否则可能只是回收策略或泄漏问题。
容器化部署时要同时核对容器内存限额与节点规格：节点内存充足但容器限额过低，同样会触发 OOM。
用不断升配掩盖内存泄漏会让成本持续失控，先定位泄漏点再谈规格，顺序反了问题永远存在。
缓存类业务还要看淘汰策略与热点分布：淘汰策略配置不当会让命中率骤降、后端压力反弹，扩容内存只能缓解症状，替代不了容量与热点的设计。