根据工作负载预算确定 SaaS VPS 规格

选择主机前先明确工作内容

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

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

在内存工作表中纳入重叠

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

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

这太接近标称 4 GB 范围，无法假设容量充裕。检查主机报告的实际内存以及峰值是否重叠。降低并发、移动组件或增加内存；不要为了适应表格而移除保留量。

PostgreSQL work_mem 是每操作配额，而不是数据库总限制。并发会话和操作可能使其效果成倍增加。Docker 容器默认没有 CPU 或内存限制；镜像不是资源策略。

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

将 CPU 与队列年龄一起测量

同时模拟普通请求、最慢的有用报告、失败的依赖和导出。在同一时间间隔内记录延迟百分位数、错误、主机 CPU、工作进程并发和最旧作业年龄。CPU 压力伴随队列增长与低 CPU 伴随长时间数据库等待表明需要采取不同行动。

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

为下一次维护操作做预算

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

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

写下可重新审视的决策

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

比较 App 2 y Scale 4 与这些约束。如果结果仍然让你意外， 跟踪一个慢请求穿过整个堆栈。此练习估算你的工作负载；它不建立供应商基准、流量容量或可用性。