容量压测怎么做
容量压测是一套方法而不是一次命令执行：先明确目标（验证容量、验证稳定性还是找瓶颈），构造接近业务的负载模型，阶梯加压直到某个资源出现拐点，同时记录服务端与系统两侧的数据，最后产出容量结论与风险清单。
基本信息
| 目标类型 | 容量评估、稳定性验证、瓶颈定位 |
|---|---|
| 负载模型 | 读写比、键分布、值大小分布、并发模型 |
| 加压方式 | 阶梯式递增，直到指标出现拐点 |
| 双侧记录 | 服务端指标与系统指标在同一时间窗口采集 |
| 产出物 | 容量结论、瓶颈资源、风险清单与扩容建议 |
典型使用场景
- 新系统上线：确定单实例能承载多少业务量
- 扩容决策：拐点落在哪个资源，就扩哪个资源
- 配置验证：对比不同持久化策略或线程配置下的承载能力
- 变更准入：大版本升级前用同一模型回归一次
- 降级演练：模拟部分节点不可用时的剩余容量
- 成本预算：把容量结论作为资源采购的依据
压测与采集
压测与采集
memtier_benchmark --ratio=1:9 --key-pattern=G:G --clients=30 --threads=4 -n 50000 # 业务感负载
redis-cli INFO stats | grep -E 'instantaneous_ops_per_sec' # 服务端吞吐视角
redis-cli INFO cpu # 主线程是否已经饱和
redis-cli INFO memory | grep -E 'used_memory_rss|mem_fragmentation_ratio' # 内存与碎片
redis-cli INFO clients | grep -E 'connected_clients' # 连接规模
vmstat 5 # 系统层 CPU 与上下文切换
iostat -xz 5 # 磁盘是否成为瓶颈拐点判读
| 资源 | 拐点信号 | 扩容方向 |
|---|---|---|
| 单核 CPU | 单核打满，延迟随并发上升 | 分片或优化命令结构 |
| 内存 | 开始出现淘汰或 OOM 风险 | 扩容内存或收敛数据 |
| 网络 | 带宽饱和，吞吐不再增长 | 提升带宽或拆分流 |
| 磁盘 | 刷盘延迟抬高 | 换更快介质或调整持久化策略 |
| 连接数 | 连接上限被顶住 | 上调上限并配足文件描述符 |
压测的价值在拐点数据：哪个资源先饱和，扩容就该针对哪里，单纯看峰值吞吐数字说明不了太多问题。
负载模型要能被复现：固定随机种子、参数与数据规模，否则两次压测之间的差异无法归因到任何一次改动。