監控顯示 CPU 積分持續下降，網站或 API 的回應時間也在變長，但單看 CPU 使用率還不能證明效能下降就是積分耗盡造成。
這篇適合負責雲主機日常運維、需要找出可複核效能證據的人。
也適合編列基礎設施預算，或負責網站與資料庫、正在評估更換執行環境的人。
先確認突發型雲主機 CPU 積分耗盡的實際影響
CPU 積分機制通常讓執行個體在低於基準效能時累積額度，並在高於基準時消耗額度；但累積、扣除與額度用完後的行為，必須按平台及執行個體系列分別核對，不能把一種雲主機的規則套到所有服務。
例如，特定雲端的 B 系列模型以基準 CPU 效能和積分收支管理突發負載；相關官方說明指出，額度用完後的運作會受基準效能限制。另一種突發型方案則分為標準模式與無限模式：標準模式的超額使用行為不同於無限模式，而無限模式的額外 CPU 使用可能產生費用。這些是各自系列的規則，不代表所有突發型虛擬機都會限速，或一定會額外收費。請分別核對特定 B 系列的 CPU 積分模型、突發型執行個體的積分與基準概念、標準模式規則及無限模式費用示例。
排查時先回答三件事：目前是哪個系列、採用哪種執行模式、額度歸零後會發生什麼。以「CPU Credit Remaining」為例，它是餘額指標，不等同於 CPU 使用率；看到它下降，只能說明積分正在消耗，還不能單獨證明業務已被限速。
第一步：把積分、負載和服務症狀放進同一時間軸
到雲端監控介面或其 API 查找該系列支援的積分餘額、積分消耗和 CPU 使用率指標，再將相同時段的服務表現一起記錄。不同平台的指標名稱、可用範圍與更新方式可能不同，應以適用系列的監控文件為準；可參照虛擬機監控指標參考、積分監控指標說明及監控指標定義文件。
| 時間段 | CPU Credit Remaining／餘額 | 積分消耗／CPU 使用率 | 業務延遲、錯誤或佇列 | 同時發生的工作 |
|---|---|---|---|---|
| 平常時段 | 記下起點與變化方向 | 記錄平均值與尖峰時段 | 記錄回應時間或待處理量 | 記下背景工作與流量變化 |
| 異常時段 | 記下餘額是否接近用盡 | 對照 CPU 是否長時間偏高 | 標出服務開始變慢的時間 | 記下部署、批次工作或並行變更 |
| 恢復時段 | 記下餘額是否回升 | 查看 CPU 壓力是否下降 | 確認服務是否同步恢復 | 記下採取的處置 |
表格不必一開始就追求完整；重點是保留原始時間範圍，並確認監控資料的時間粒度。若積分先下降、CPU 長時間高於基準、接著延遲上升，這是值得進一步驗證的關聯；若三者時間對不上，就要繼續找其他原因。
第二步：排除程式、流量與其他資源瓶頸
積分餘額低不代表應用本身沒有問題。按異常發生時間檢查程式日誌、流量變化、排程任務及近期部署；再查看記憶體、硬碟 I/O 與網路指標是否同時異常。若只是批次工作突然增加，調整執行時段或並行度可能比更換整個執行環境更直接。
建議逐項勾選，避免以單一監控數字下結論：
- [ ] 已確認執行個體型號確實使用 CPU 積分，而非依名稱或印象推測。
- [ ] 已查明適用系列在積分用盡後的行為，以及是否有不同執行模式。
- [ ] 已將積分餘額、積分使用、CPU 使用率與業務延遲對齊。
- [ ] 已檢查程式日誌、定時任務、部署紀錄與流量變化。
- [ ] 已查看記憶體、硬碟 I/O、網路等其他可能瓶頸。
- [ ] 已記下變更前的指標與恢復條件，避免測試後無法判斷效果。
不要把 CPU 積分耗盡與 CPU steal 混成同一問題：前者是特定雲端執行個體的積分模型，後者是另一類 CPU 排程觀察值，需用相應的監控證據分別判讀。遇到高 CPU 狀況時，也可參照官方虛擬機高 CPU 排查建議，但仍須按實際作業系統與執行個體類型調整檢查項目。
第三步：按負載特徵選擇處置方案
把最近的實際帳單、官方計價頁和業務負載放在同一週期比較，不要只比較單一執行個體的標價。按量計費可能還涉及其他資源與流量項目；若選擇無限模式，也要確認適用的額外積分計價規則。應記下價格適用區域與查詢日期，本站方案則依當期產品資料核對。若需要整理整體費用，可參考伺服器費用核算頁面。
| 方案 | 較合適的負載情況 | 先核對的風險與成本 |
|---|---|---|
| 保留原突發型規格 | CPU 多數時間低於基準，只有短暫尖峰 | 積分是否能在低負載時回補；尖峰期間是否再次耗盡 |
| 調整突發型規格或執行模式 | 當前資源不符合負載，但仍需要雲端彈性 | 規格差額、額外積分費用及改動後的退回方式 |
| 固定效能雲端方案 | 負載經常超出基準，且希望維持雲端管理方式 | 同一帳期的總成本、磁碟與網路資源，以及擴縮容要求 |
| 評估獨立伺服器租用 | 負載穩定、需求可預估，團隊能承擔自主管理 | 硬體故障、備份與還原、監控及維護責任 |
先依下列條件分流，再進入採購或遷移評估：
- 若積分只在短時工作中下降、服務指標仍符合要求：先保留原方案，調整排程或限制尖峰並行，持續觀察同一組指標；若症狀反覆出現，再比較調整規格。
- 若日常負載長期高於基準，且積分下降與延遲惡化反覆同步：優先比較更高規格或固定效能雲端方案；若仍考慮獨立伺服器，先核對應用依賴與團隊維運能力。
- 若負載強烈波動、需要快速擴縮、多區部署，或深度依賴託管資料庫、訊息佇列及無伺服器服務：先保留雲端或採混合部署，不宜只為了積分告警就直接遷出。
- 若資源需求穩定、單機可承載，且已有備份、監控與故障復原流程：才把獨立伺服器列入候選，並以可回退的小範圍測試確認適配性。
用小範圍驗證結果，不用推測代替決策
在更換規格或遷移前，先選一組能代表正式服務的工作負載，記錄 CPU、積分餘額、回應時間、錯誤、佇列與資源消耗。測試環境或可回退的變更應使用相同程式版本、資料特徵與流量條件；若測試負載不同，就不能把結果直接當作正式環境的保證。
預先寫下驗收條件，例如服務延遲是否回到團隊既有目標、尖峰時是否再度觸發限制、資料能否按流程還原，以及成本是否落在核准範圍。測試後比較實際紀錄，而非預設調整規格或搬遷一定會提升效能、降低費用。
遷往獨立伺服器前，還要確認應用依賴、記憶體與硬碟容量、頻寬需求、備份位置、還原步驟及值班責任。獨享實體資源不會自動提供高可用、資料備份或代為維運；若團隊無法處理硬體故障和復原，應先補上責任與流程，再決定是否遷移。
常見問題
CPU 積分用完後，服務會立即停止嗎？
不一定。依平台與執行個體系列而異，可能回到基準效能，也可能有其他模式與費用規則。先查實際型號及執行模式，再把積分、CPU 使用率與服務指標對照；不要把某一系列的限制方式當成所有雲主機的共同規則。
怎樣查看積分餘額與消耗速度？
在該平台的監控介面查找積分餘額與消耗指標，並確認指標適用於目前系列。將它們與 CPU 使用率、延遲及佇列按相同時段記錄；若只有餘額下降而服務指標正常，應持續觀察，不必立即換規格。
積分一直下降，就該換更大規格嗎？
要看下降是否發生在正常業務時段，以及是否持續伴隨高 CPU 和服務變慢。若只在短時批次工作中發生，可先調整排程或並行度；若日常負載長期高於基準，才比較提高規格、改用固定效能雲端方案或評估遷移。
網站或資料庫長期運作，適合突發型虛擬機嗎？
若大部分時間負載低、偶爾才短暫突增，突發型虛擬機仍可能適用；若 CPU 長期超過基準，積分反覆耗盡，就應比較固定效能方案。獨立伺服器則要同時評估資源穩定度、維運能力與故障復原責任，不能只看 CPU 積分。
依負載核對獨立伺服器是否接得住
突發型雲主機適合短時尖峰與變化較大的負載，但長期受基準效能限制時，積分消耗可能讓效能和費用都更難預測。固定效能雲端方案可以保留雲端管理方式；獨立伺服器則提供獨享實體資源，但需要團隊自行規劃備份、監控與復原，也不適合強彈性、多區域或深度依賴託管服務的工作負載。
若負載已穩定，且團隊能承擔上述責任，可先依獨立伺服器可選配置核對資源與當期產品資料，再用測試結果評估是否遷移。XFP Cloud 的獨立伺服器應與現行雲端方案按同一帳期比較；在實際配置、費用與恢復流程核實前，不應假設遷移必然更快或更省。
最後更新於 2026-11-02；積分模型與監控指標核實自本文所引官方文件，平台規則須按實際系列確認。
常見問題
突發型雲主機的 CPU 積分用完後，服務一定會停掉嗎？
不一定。不同平台與執行個體系列的積分規則不同，有些會在餘額耗盡後回到基準效能，有些則另有可持續突發及額外費用規則。應先查清實際系列、執行模式與監控指標，再將積分變化對照延遲、錯誤率和佇列，不能只憑餘額歸零便判定服務必然中斷。
要從哪裡確認 CPU 積分餘額和消耗速度？
先在雲端監控服務查找該系列支援的積分餘額與使用量指標，例如 CPU Credit Remaining、CPUCreditBalance 或 CPUCreditUsage；名稱會依平台而異。把相同時間段的積分、CPU 使用率、請求延遲及佇列長度放在一起看，並留存原始時間範圍，才能分辨積分下降是否與服務變慢同步。
CPU 積分持續下降，什麼情況下該換更大規格？
若業務在正常營運時段也長期超過該型號的基準效能，且 CPU 壓力與延遲惡化反覆同時出現，就應把調整規格或改用固定效能方案納入比較。若下降只出現在批次工作或短暫尖峰，先調整排程、並行度或尖峰處理方式，再用代表性負載驗證，通常比立即搬遷更容易控制風險。
網站或資料庫長時間運作，還適合用突發型虛擬機嗎？
若網站或資料庫的 CPU 負載大多低於基準，只在短時任務中突增，突發型虛擬機仍可能合用；若長時間高負載、積分反覆見底，則應比較固定效能雲端方案。獨立伺服器也只適合資源需求相對穩定、團隊能自行負責備份、監控與故障復原的情況，並非所有服務的預設答案。