测量之前
使用您控制的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 活动表明正在交换;仅分配交换空间并不能证明当前存在压力。 wa 和 st 需要结合上下文而非自动升级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 估计所选树,受访问权限限制。这些是不同的问题,因此它们的总计不必匹配。请参阅 df 和 du.
列出当前数据库、上传、日志、应用程序产物以及任何本地备份暂存空间。将发布所需的空间与上一个发布一起添加,然后估计下一个审查间隔内的增长。例如,每天100 MiB的新上传在30天内增加约3,000 MiB(在副本或备份之前)。将结果与目录比较时,一致地标记十进制GB和二进制GiB。
对于传输,一个示例20 kB响应发送50,000次约为1 GB的响应负载。加上上传、静态文件、协议开销和备份流量。该算术估计的是量,而不是吞吐量或同时用户数。确认服务如何计算流量并处理任何超额。
选择下一步操作并检查
- 正常峰值期间可用内存低:检查主要消耗者并测试更大的内存预算。
- 持续CPU压力下请求缓慢:分析繁忙路径,然后使用相同工作负载比较CPU变化。
- 磁盘使用增长:在删除任何内容之前,确定负责的目录和保留策略。
- 资源看起来充足但应用缓慢:调查依赖项、查询和请求路径。
保存工作表,包含工作负载描述、采样时间、单位和下次审查日期。在重大发布、数据增长或添加工作进程后重新检查。根据这些观察选择配置;没有计划名称能保证请求容量。继续阅读 阅读内存和磁盘警告 或 第一个API资源场景.
使用的文档
本页的主要参考资料。检查您自己环境中安装版本的文档。