按工作负载预算规划 SaaS VPS 规模

在选择主机前先明确工作

绘制请求路径：反向代理、API 进程、数据库和外部服务。添加异步路径：队列、worker 和导出目标。记录哪些组件共享主机、谁控制并发以及哪些数据必须在重建后保留。你需要应用指标和具有代表性数据的非生产工作负载；本指南不假设已配置 PrivacyNodes 实例。

以一个示例报告 API 为例，一次 HTTP 请求读取账户设置并入队一次导出。worker 扫描行并写入文件。快速入队响应不能证明导出能在高峰流量期间完成。将计划清理和部署重叠纳入测试计划。

将重叠计入内存工作表

这些是以 MiB 为单位的假设性规划输入，不是测量值或对 PrivacyNodes 的承诺。请用观测到的应用需求替换它们。RSS 包含驻留共享映射；将每个进程的 RSS 相加可能重复计算内存。主机的可用内存比将所有文件系统缓存视为永久不可用更有用。

技术参考： Linux 进程内存核算.

这太接近名义 4 GB 包络，不能假定容量宽裕。检查主机报告的实际内存以及峰值是否重叠。降低并发、迁移组件或增加内存；不要仅为让表格匹配而移除预留。

PostgreSQL work_mem 是每次操作的限额，而不是数据库总限制。并发会话和操作可能放大其影响。Docker 容器默认没有 CPU 或内存限制；镜像不是资源策略。

技术参考： PostgreSQL 资源消耗 · Docker 资源约束.

在测量 CPU 的同时关注队列年龄

同时演练一次普通请求、最慢的有用报告、一次依赖故障和一次导出。在同一时间段内记录延迟百分位数、错误、主机 CPU、worker 并发和最旧作业年龄。CPU 压力伴随队列增长与低 CPU 伴随长时间数据库等待提示不同操作。

以一次导出在途开始示例。如果 worker 等待外部存储，增加 CPU 可能影响甚微。如果它在 API 延迟上升时反复占满一个核心，测试更小的导出批次或单独的 worker 预算。在购买容量前改变一个因素并重复相同场景。

为下一次维护操作预留预算

列出数据库文件和索引、上传、日志、临时导出、发布构件以及用于维护的可用空间。记录每周增长以及预留何时耗尽。一个 20 GB 数据集加一个 20 GB 临时副本需要超过 20 GB，即使普通应用流量处于低峰。

分配日志轮换和导出过期。将恢复副本保存在主机故障边界之外。额外 VPS 存储扩展的是工作分配；同一磁盘上的副本不是独立备份。测试正常运行以及发布与备份或导出同时进行。

写出可重新审视的决策

你的输出是一份工作表、一份工作负载描述和一个审查触发条件：代表性测试期间最旧作业年龄增长、维护空间缩减，或发布无法与当前进程共存。记录观察结果，而不是编造通用 CPU 百分比阈值。

比较 App 2 和 Scale 4 与这些约束。如果结果仍让你意外， 沿调用栈追踪一个慢请求。本练习估算你的工作负载；它不建立任何供应商基准、流量容量或可用性。