加上同时内存预算
从重叠的进程开始，而不是它们的平静平均值。一个示例性 4 GB 工作表可为宿主工具预留 700 MiB、为 API 进程预留 900 MiB、为数据库预留 1,200 MiB、为一个工作进程预留 500 MiB，并为不确定性预留 700 MiB：总计 4,000 MiB。这几乎耗尽标称套餐，几乎没有余量来应对更大的发布重叠。
根据实测工作估算 CPU 需求
测量一个代表性请求或作业的 CPU 时间，然后乘以峰值完成率。例如，25 毫秒 CPU 时间 × 每秒 20 个请求 = 每秒 500 毫秒 CPU，或平均 0.5 核。在有一个真实工作进程活跃时重复测量并检查峰值；平均值会掩盖突发、调度和数据库等待。
区分限制信号
| 观察到的信号 | 可能的下一项检查 |
|---|---|
| 高 CPU 且存在可运行工作 | 分析热路径，然后比较增加 CPU。 |
| 内存压力或进程终止 | 减少重叠或增加实测 RAM。 |
| CPU 低但请求缓慢 | 检查数据库、连接池和外部等待。 |
| 工作进程增加时队列等待时间上升 | 降低并发并检查共享依赖。 |
做出资源决策
仅当性能分析显示持续的算力争用时，才选择更多 CPU。当同时工作集缺乏余量时，选择更多 RAM。当并行工作损害 API 延迟或有效完成率时，降低并发。记录触发测量值，然后在更改一个变量后重复相同工作负载。