游戏卡顿白皮书 › L11 磁盘
云盘突发积分耗尽 Burst credit depletion
原因 ID dk-burst · 主责 运维团队·系统运维 · 配合 运维团队·数据库运维
在含图示和实验的完整版中打开此卡片 →
部分云盘和小规格实例有突发积分，可以短时间超过基准性能运行。繁忙时段一长、积分耗尽，速度就会突然下降。
起因 长时间以高于基准性能的水平运行 → 结果 突发积分耗尽，性能骤降到基准水平 → 画面表现 每天晚上过了几个小时后开始卡
- 症状
- 一卡一卡, 慢动作, 操作延迟
- 因素
- 停顿, 延迟
- 谁会遇到
- 全服
- 何时出现
- 晚高峰, 开得越久越严重
- 负责方
- 主责 运维团队·系统运维 · 配合 运维团队·数据库运维
- 运维团队要做的事
- 服务器/OS：换成性能有保障的磁盘（gp3、预置 IOPS 型），为积分余额设告警，同时检查实例的磁盘带宽突发上限和 CPU 积分。DB 服务器：包括托管数据库在内，DB 磁盘也换成性能有保障的类型，并为积分余额设告警。
- 数值参考
- AWS gp2 100 GB 磁盘平时 300 IOPS，突发时 3,000 IOPS，积分满时约能撑 30 分钟。gp3 没有积分，始终是 3,000。Azure 的小容量 Premium SSD 也靠积分最多突发 30 分钟。
- 监控图上
- 触顶后走平 · IOPS、突发积分余额
- 查看位置
- 看 CloudWatch 中 EBS 的 BurstBalance（gp2、st1、sc1），实例的 EBSIOBalance%、EBSByteBalance%（部分可突发的实例），以及突发型实例的 CPUCreditBalance。Azure 看 Data Disk Used Burst IO Credits Percentage 等突发积分使用率指标
- 确认依据
- 从余额掉到接近 0 的时刻起，IOPS（VolumeReadOps、VolumeWriteOps）在基准性能处走平，VolumeQueueLength 和卡顿一起增加。在高峰持续几小时之后开始
- 排除依据
- 各项余额都充足而 IOPS 走平，是卷或实例的固定上限，看“IOPS 上限/队列饱和”（dk-iops）
- 确认手段
- 运维工具即可确认（无需游戏代码）
- 深入了解
- 即使磁盘没问题，小规格虚拟机的实例磁盘带宽也有突发上限（每天至少 30 分钟等），同样会出现这种曲线。使用 CPU 积分的低价实例，积分耗尽后也会降到基准性能。
出处
- Amazon EBS General Purpose SSD volumes AWS
gp2 基准性能为每 GiB 3 IOPS（最低 100），靠 I/O 积分可突发到 3,000 IOPS，540 万积分至少能撑 30 分钟。gp3 没有突发，始终 3,000 IOPS - Managed disk bursting Microsoft Azure
P20 及以下的 Premium SSD 基于积分突发，积分满时能以最大突发速度运行 30 分钟 - Amazon EBS-optimized instance types AWS
部分实例每 24 小时只能维持一次 30 分钟的 EBS 最大性能，之后回到基准性能 - Standard mode for burstable performance instances AWS
标准模式的突发型实例在 CPU 积分用完后，会把 CPU 使用率降到基准水平（逐步降低，不会骤降） - Amazon CloudWatch metrics for Amazon EBS AWS
BurstBalance：gp2 的 I/O 积分、st1 和 sc1 的吞吐量积分余额（%），VolumeReadOps、VolumeWriteOps、VolumeQueueLength - CloudWatch metrics that are available for your instances AWS
EBSIOBalance%、EBSByteBalance%：部分每 24 小时可突发一次 30 分钟的实例的 EBS 积分余额，CPUCreditBalance：突发型实例的 CPU 积分余额 - Disk metrics Microsoft Azure
Data Disk Used Burst IO Credits Percentage 等磁盘、VM 突发积分使用率（5 分钟粒度）
相关原因
同一层：L11 磁盘
其他层中同样导致“一卡一卡”的原因
查看含图示和实验的原卡片