判断框｜适合：如果所用实例确实采用 CPU 积分机制，而且积分余额下降与业务响应变慢发生在同一时段，先核对平台规则和监控证据，再决定调整规格或评估迁移；若只是看到 CPU 使用率升高，暂时不要把原因归结为积分耗尽。
这篇文章适合负责云主机运维、基础设施预算，以及网站、API 或数据库应用的人。
目标是把“积分减少”和“业务变慢”对应到同一时间轴，排除其他瓶颈，再选下一步方案。
最后更新于 2026 年 11 月 2 日；数据核实自云平台官方积分与监控文档，以及 XFP Cloud 配置与计费页面。
先确认突发型云主机 CPU 积分耗尽会触发什么
突发型虚拟机通常在低于基准 CPU 性能时累积积分，在高于基准时消耗积分；积分耗尽之后怎么处理，取决于具体平台、实例系列和信用模式，不能只凭“积分为零”推断所有机器都会以同一种方式限速。
例如，微软 B 系列官方文档说明，该系列在积分用完后会回落到基准 CPU 性能，直到重新累积积分后才能再次突发；同一文档还列出基准性能、积分余额、积分消耗和 CPU 百分比等概念。这个结论适用于文档明确说明的 B 系列，不代表所有云主机规则。可对照官方 B 系列 CPU 积分模型查看适用范围。
另一个官方实例系列的规则则区分标准模式和无限模式：标准模式下，实例使用已累积积分在基准之上突发；无限模式可继续使用额外积分，但可能产生额外费用。是否限速、是否额外计费，要以实例实际信用模式和账单项目为准，不能把一种行为误认为另一种。可参照突发型实例信用模式说明和标准模式规则。
积分见底后的平台行为
先查实例系列和信用模式，再看官方对“余额归零”的定义。若该系列会回到基准性能，业务可能表现为处理时间拉长、请求排队或数据库查询变慢；若该系列支持无限模式，还要核对额外积分和费用指标。两种情况都需要用当前实例的官方资料确认，而不是套用别的平台规则。
先对齐积分、CPU 与业务时段
单看 CPU Credit Remaining 只能说明余额变化，不能说明用户请求为何变慢。把积分余额、积分消耗、CPU 使用率，与 API 响应时间、队列长度或数据库负载对齐，才能判断它们是否同步变化。
不同平台的指标名称和采样方式并不相同。例如，官方监控参考资料列出 B 系列的 CPU Credits Remaining、CPU Credits Consumed 和 Percentage CPU，并说明相关指标可按 1 分钟时间粒度查看；另一平台的 CPU 积分指标则为 5 分钟频率。采样粒度不同，短时波动看起来也会不同，须按实际指标定义解读。参见官方虚拟机监控指标参考与官方 CPU 积分监控指标说明。
查看积分余额与消耗趋势
先在平台监控页或监控 API 中确认实例是否提供积分指标，再记录指标名称、单位、统计方式和采样频率。如果平台显示 CPU Credits Remaining，同时也提供积分消耗和 CPU 百分比，应一起导出；如果指标不存在，不要用 CPU 使用率估算一个并不存在的积分余额。还可参考官方监控数据定义核实指标含义。
把记录整理成下面的时间段对照，使用实例自己的监控数据填写，不要用其他机器或不同采样周期的数据代替：
| 对照项 | 积分持续下降时 | 余额接近或归零时 | 同期业务表现 |
|---|---|---|---|
| CPU 积分余额与消耗 | 记录余额和消耗方向 | 记录余额是否归零、消耗是否停止或改变 | 记录响应时间、超时、告警 |
| CPU 使用率与进程 | 标记持续占用的进程和负载 | 查看进程、负载是否仍持续 | 对照请求量、任务运行情况 |
| 队列与数据库 | 记录积压、连接和查询变化 | 标记变化开始时间 | 对照队列长度、查询延迟 |
| 磁盘与内存 | 查看 I/O、可用内存和交换活动 | 核对是否出现同步异常 | 避免把其他资源瓶颈归给 CPU 积分 |
再排除应用和其他资源瓶颈
在修改实例前，按业务变化排查原因。应用发布、流量突增、定时任务、后台批处理或并发提高，都可能推高 CPU 消耗；磁盘 I/O 等待或内存压力也会使请求变慢，但不一定能由 CPU 积分指标解释。
✅ 核对应用日志与发布记录：确认性能下降前是否有版本变更、异常重试或任务启动。
✅ 对照流量和并发：确认请求量是否增加，变化是否集中在特定业务时段。
✅ 检查定时任务与队列：观察批处理、备份或队列积压是否与积分消耗同步。
✅ 查看内存与磁盘指标：分别核对可用内存、交换活动、磁盘延迟和 I/O 等待。
✅ 比较系统和平台监控：区分实例内部 CPU 使用与平台提供的 CPU 指标；不要把 CPU steal 当作积分耗尽的同义词。
✅ 记录问题复现时间：保存同一时间段的监控图、日志和业务告警，便于复核和回滚判断。
平台侧高 CPU 排查文档也建议先识别负载来源，并按工作负载验证规格，而不是仅凭实例大小推断表现。可参考官方高 CPU 问题排查建议。
按负载形态比较下一步方案
积分长期净消耗时的规格判断
如果余额长期净下降，同时 CPU 负载和业务延迟持续偏高，应比较更大规格、固定性能实例或其他部署方式；如果只在短时峰值下降、低谷期能够回补，而且业务仍满足响应目标，可以先保留原规格并观察。不要在未核对费用模式时把“无限突发”当作免费解决方案；官方文档明确指出，额外积分在特定条件下可能产生费用，可查看官方信用配置操作说明和无限模式示例及费用计算规则。
| 方案 | 更匹配的负载 | 成本核对口径 | 主要复核点 |
|---|---|---|---|
| 保留原突发型实例 | CPU 高峰短、低谷能回补，业务延迟仍合格 | 同期实例账单、积分相关费用及监控记录 | 积分是否有恢复时段，峰值是否影响关键请求 |
| 调整规格或改用固定性能实例 | CPU 长时间高于基准，或负载增长较稳定 | 相同区域、相同账期的官方价格页与实际账单 | 更换前确认规格、应用兼容性与扩缩容要求 |
| 评估独立服务器 | 负载较稳定、资源需求可估算，团队能够承担运维 | 当前云账单与本站产品表按相同账期核算 | 内存、磁盘、网络、备份恢复和故障处置责任 |
持续运行的网站或数据库适不适合突发型实例
能否继续使用，取决于负载是否常常超过基准，而不是“网站”或“数据库”这类标签。若日常 CPU 占用就使积分不断净下降，且低谷没有足够时间回补，应把固定性能方案纳入比较；若只有偶发突发，并且使用体验与账单都可接受，迁移并不一定有优势。
决策条件列表：
- 若积分下降与业务变慢在同一时段反复出现，且实例官方规则确认余额耗尽会降低可用 CPU 性能，则先验证调整规格或固定性能实例。
- 若积分下降但业务延迟稳定、队列正常，且低谷期能够恢复余额，则先保留原实例，继续监测并核对账单。
- 若负载长期稳定、资源需求可预测，团队有系统管理、监控和恢复能力，则将独立服务器列入同周期成本比较。
- 若依赖强弹性、多区域快速扩展或深度托管服务，则优先保留云端或采用混合部署，不要仅因积分告警就整体迁移。
迁移前核对资源和运维责任
独立服务器把资源使用方式从突发型实例改为整机资源规划，但这不自动提供高可用、备份服务或代运维。迁移评估应先核对业务依赖、数据恢复路径和团队能否承担系统维护，再判断成本是否值得。
XFP Cloud 当前配置页列出 AMD EPYC 7543P、32 核 / 64 线程，并提供 128GB 或 256GB 内存选项；默认包含 2 块 1TB NVMe 直连盘，可用容量为 2TB，并注明没有硬件 RAID。月租起价为 455 美元，页面列出的机房为日本东京；该价格和配置核对于 2026 年 11 月 2 日，应以下单时的本站配置页面及本站计费说明为准。此处列出的只是可供比较的机器规格，不代表应用迁移后必然更快或更便宜。
在采用该方案前，至少逐项确认：
✅ 应用是否依赖云平台专属 API、托管数据库、托管队列或无服务器组件。
✅ 数据库、容器、日志和备份的实际容量是否满足磁盘与内存规划。
✅ 带宽、出网模式、地址需求是否与业务网络要求相符。
✅ 是否已有机外备份、恢复演练和硬件故障后的替代恢复流程。
✅ 团队是否能负责操作系统更新、监控告警、服务恢复与日常排障。
用小范围验证决定是否扩大调整
不要把积分归零后的短时表现当成最终迁移结论。先挑选能代表日常负载的测试环境或可回滚变更，并提前定义观察指标；测试失败时恢复原方案，而不是直接扩大变更范围。
✅ 记录变更前的 CPU、积分、业务延迟、队列、内存与磁盘指标。
✅ 选择一段具有代表性的业务负载，确认测试期间没有同时发布或批量任务等干扰因素。
✅ 对候选规格或部署方式运行同一组请求与任务，记录结果及账单项目。
✅ 检查应用依赖、监控告警、备份恢复和回滚流程是否都能正常工作。
✅ 由业务负责人确认验收指标；未达标或无法恢复时，回到原方案并查明原因。
针对积分余额归零后持续受限的机器，验证期间也要观察平台定义的积分和 CPU 指标；并非所有平台都会以相同方式恢复或计费。尤其是无限模式实例，需把额外积分指标与账单同时核对，避免只看 CPU 使用率而漏掉费用变化。
如果问题只是突发型云主机的积分模型不适配持续负载，调大实例或改用固定性能实例可能更直接；如果长期运行的业务资源稳定、但现有共享实例存在性能波动、资源计费分项难核对，或磁盘和系统选择受限，再把独立服务器租用纳入同周期比较。XFP Cloud 的配置与计费页面可用于核对实际资源和金额，但是否适合迁移仍应由前面的负载验证、恢复方案和团队责任共同决定。