AWS EBS突发余额消耗异常问题求助

Hey there, let's break down why your EBS credits are still being used even after moving the database to RDS, and walk through how to diagnose and fix this.

什么是EBS突发信用额度（Burst Credits）？ #

EBS突发信用额度是为gp2通用型SSD卷设计的，用来应对短时间的IO峰值。针对你的16GB卷，规则是这样的：

• 基准性能为每GB 3 IOPS，所以你的卷基准IOPS是48。
• 当实际IOPS低于48时，会积累信用额度（每秒积累的量等于基准IOPS与实际IOPS的差值）。你的16GB卷最大信用池容量为576,000个信用点——足够支撑gp2最高3000 IOPS的突发性能运行约192秒。
• 当实际IOPS超过48时，就会消耗信用池里的额度。额度耗尽后，卷会被限制在48 IOPS的基准性能，直到信用额度重新积累。

为什么迁走数据库后仍在消耗信用额度？ #

迁移数据库确实移除了一大IO消耗源，但EC2上的EBS卷仍在处理其他持续超过48 IOPS基准的操作，常见原因包括：

• Web应用静态资源读取：如果用户访问量较大，直接从EBS读取图片、CSS、JS等静态文件，会产生大量随机读IO，突破基准阈值。
• 应用/日志写入：如果Web应用开启了DEBUG级别的日志，或者在EBS卷上生成大量临时文件、本地缓存，持续的写入IO会不断消耗额度。
• 系统层面IO：操作系统日志（如/var/log/syslog或Web服务日志）的写入、swap交换（EC2内存不足时，会频繁将数据交换到EBS）、定期系统任务（日志轮转、备份、磁盘检查）等，都会贡献IO消耗。
• 隐藏的后台进程：可能有遗留的备份脚本、监控代理，或者仍在访问EBS上旧数据库文件的进程，即使你已经迁移了活跃数据库。

诊断与解决步骤 #

我们一步步来定位问题并优化：

1. 通过CloudWatch查看EBS指标
   登录AWS控制台，找到你的EBS卷，查看以下CloudWatch指标：

   • VolumeReadOps和VolumeWriteOps：计算总IOPS（两者之和除以时间间隔），确认是否持续高于48 IOPS。
   • VolumeBurstBalance：显示剩余信用额度的百分比，如果它持续下降，说明你处于持续突发IO状态。

2. 用命令行工具排查EC2磁盘IO

   • 在EC2实例上运行iostat -x 1（若未安装，可通过apt-get install sysstat或yum install sysstat安装）。查看EBS设备（通常是/dev/xvda或/dev/nvme0n1）的r/s（每秒读取次数）和w/s（每秒写入次数）列，如果两者总和持续高于48，那就是消耗来源。
   • 使用iotop工具（安装方式同上），可以精准看到哪个进程在占用IO，比如是Web服务器（Nginx/Apache）、日志进程还是其他后台程序。

3. 优化核心IO消耗源

   • 静态资源：配置CDN（如CloudFront）缓存图片、CSS和JS，几乎可以完全卸载EBS的读取IO压力。
   • 日志配置：将应用日志级别从DEBUG调整为INFO/WARN，同时配置日志轮转，避免持续写入超大日志文件。
   • Swap优化：运行free -h检查swap使用情况，如果频繁使用swap，要么升级EC2实例增加内存，要么优化应用减少内存占用（比如减少工作进程数）。
   • 清理遗留文件：删除EBS卷上的旧数据库文件、备份或未使用的数据，避免被意外访问产生IO。

4. 考虑切换到gp3卷
   如果你的应用需要持续高于48 IOPS的性能，gp3卷会是更合适的选择。它支持独立预置IOPS（从300到16000），不需要依赖突发信用额度，性能始终稳定，无论高IO状态持续多久。

内容的提问来源于stack exchange，提问作者NeoSennin