OffVPS离岸 VPS支持

入门

按实际运行的应用规模进行配置。

从共享该机器的进程开始,测量有代表性的繁忙时段,并将部署和恢复应用的工作包括在内。仅凭访客数量估计无法确定VPS的规格。

OffVPS 现场指南 · 已审核 · 5 分钟阅读

测量之前

使用您控制的Linux测试机,其中包含您的应用和有代表性的数据。以下命令检查资源;它们不会调整内核或删除文件。您需要procps和GNU coreutils,以及检查所选应用目录的权限。替换 /srv/my-app 为其真实路径。如果应用尚未在任何地方运行,请使用其开发或预发布环境构建初始估计,然后在目标系统上重新审视该估计。

写下共享该VPS的内容:操作系统、代理、API、数据库、工作进程和监控。记录资源构建是否在此运行、备份是否在本地压缩,以及计划任务是否可能与部署重叠。一个安静的应用进程可以与昂贵的发布过程共存。

读取可用内存并识别进程

free -m
ps -eo pid,comm,rss --sort=-rss | head -n 12

free -m 报告MiB。重点关注 available,即在不交换的情况下可支持新工作的内存估计; free 单独排除了有用的可回收内存。因此,缓存本身并不是购买更多RAM的理由。请参阅 free字段定义.

Illustrative selected fields — not an OffVPS measurement
Mem total: 2048 MiB
Mem free:   180 MiB
Mem available: 800 MiB

Illustrative ps rows
  PID COMMAND     RSS
 2100 postgres 393216
 2140 node     184320
  920 caddy     32768

上述进程RSS值大致对应384、180和32 MiB。它们有助于定位内存使用,但将所有RSS值相加并不是确切的机器总量:共享页面可能被多次计数,且某些内核开销不在进程数字内。收集报告时避免打印命令行参数或环境变量,因为它们可能包含机密。 ps手册 解释了其字段和快照行为。

将观察结果转化为工作表

以下分配示例说明一个小型API与本地数据库和一个工作进程的情况。它们是虚构的规划值,不是特定框架的基准或最低要求。请替换为您的测量值,并注意哪些分配可能同时达到峰值。

组件或分配示例RAM预算
操作系统和支持服务160 MiB
反向代理32 MiB
API进程180 MiB
数据库384 MiB
后台工作进程96 MiB
额外部署工作320 MiB
增长和不确定性余量200 MiB
规划总计1,372 MiB

此工作表已超出1,024 MiB预算。2,048 MiB的测试环境在这些分配下将剩余676 MiB,但有用的结果是真实的有代表性工作是否适合且应用保持响应。如果部署分配占主导,在其他地方构建产物可能比扩大永久服务器更好。在总计旁边保留假设。

在有用工作期间观察CPU和交换

vmstat 1 10

在有代表性的请求批次、作业和发布期间运行此命令。解释最近间隔时忽略第一行:它汇总自启动以来的活动。后续行描述采样间隔。在 r中持续的可运行工作,在 id 中低空闲时间以及慢请求一起证明需要调查CPU压力。反复的 si/so 活动表明正在交换;仅分配交换空间并不能证明当前存在压力。 wast 需要结合上下文而非自动升级CPU。这些字段在 vmstat.

中定义。同时记录应用程序的响应时间。缓慢的外部API或数据库查询可能使请求等待,而CPU大部分空闲。在一次更改后重复相同的工作负载,以便了解哪项更改有帮助。负载测试应仅针对您控制的系统,并设置速率和停止条件以避免干扰其他用户。

分别预算磁盘增长和传输

df -h /srv/my-app
df -i /srv/my-app
du -sh /srv/my-app

df 描述包含该路径的文件系统,包括与其他目录共享的空间; df -i 在支持的情况下检查inode使用情况。大量小文件可能在字节容量之前耗尽inode。 du 估计所选树,受访问权限限制。这些是不同的问题,因此它们的总计不必匹配。请参阅 dfdu.

列出当前数据库、上传、日志、应用程序产物以及任何本地备份暂存空间。将发布所需的空间与上一个发布一起添加,然后估计下一个审查间隔内的增长。例如,每天100 MiB的新上传在30天内增加约3,000 MiB(在副本或备份之前)。将结果与目录比较时,一致地标记十进制GB和二进制GiB。

对于传输,一个示例20 kB响应发送50,000次约为1 GB的响应负载。加上上传、静态文件、协议开销和备份流量。该算术估计的是量,而不是吞吐量或同时用户数。确认服务如何计算流量并处理任何超额。

选择下一步操作并检查

  • 正常峰值期间可用内存低:检查主要消耗者并测试更大的内存预算。
  • 持续CPU压力下请求缓慢:分析繁忙路径,然后使用相同工作负载比较CPU变化。
  • 磁盘使用增长:在删除任何内容之前,确定负责的目录和保留策略。
  • 资源看起来充足但应用缓慢:调查依赖项、查询和请求路径。

保存工作表,包含工作负载描述、采样时间、单位和下次审查日期。在重大发布、数据增长或添加工作进程后重新检查。根据这些观察选择配置;没有计划名称能保证请求容量。继续阅读 阅读内存和磁盘警告第一个API资源场景.

使用的文档

本页的主要参考资料。检查您自己环境中安装版本的文档。