前言
此案例介绍，应用访问rds，间歇性性能抖动原因。
1 环境信息
阿里云rds：高可用系列 5.7.40 本地ssd，一主四从
2 问题描述
年初开始，业务反馈应用访问rds集群，不时出现性能抖动，表现为核心功能某模块不定期慢，skywaling抓到的SQL偶尔耗时很高，比正常时慢一个数量级。中间经过多次的联合定位，均没有结果。而且年初数据量增长较快，开始怀疑是数据量上涨导致，所以跨度较长。经过对比排除法，怀疑是数据库问题，6月份再次集中经历定位，这次和阿里云工程师开会，对问题进行了详细描述，并就一些疑问进行了咨询，最终找到原因。
精炼版问题描述：
应用A（核心模块） -> RDS 某个SQL偶尔耗时高达25ms，该表只有1条数据，审计日志全部在1ms以下；应用B（非核心模块） -> RDS；RDS的CPU使用率在25%以下，发现会话连接数比较多，1.2k，大部分来自于应用B。分析后发现应用B 开启testOnBorrow 间隔60s ，关闭后RDS连接数下降到400，应用A访问SQL就没有抖动。应用侧sql耗时看的是skywalking，应用A没有做过任何配置变更，流量也没有发生明显变化。
疑问1：该实例支持连接数1W，为什么1.2k就影响性能了，且此时数据库负载不高。回答：rds代理规格低，cpu满了
疑问2：审计日志耗时是否包含数据连接池的耗时。rds因为线程阻塞或上下文切换的耗时是否包含。回答：包含
3 排查
查看代理cpu使用率，确实问题时间段cpu满了。代理规格为 2核（代理个数1)。
4 解决方案
升级代理规格为 4核（代理个数2高可用）。按照经验，代理cpu使用率别超过70%，一般不影响性能。延伸：
定位到问题后解决方案就很快了，但是该问题困扰很久，主要以下原因：
1）使用rds很久了，连接数都没超过1k，所以没出过问题。一直没有关注过代理cpu使用率，且代理监控页面比较隐蔽。
2）还是要相信自己，根据对比排除法，很容易判断出是数据库侧问题，尤其审计日志执行时间一直很正常（1ms以下），更能推测是代理问题。之前已经无限接近过，但只看了代理配置，没看到代理监控。
3）开始提工单没解决，经过电话会议才描述清楚问题并解决。
4）官方文档没有关于代理cpu使用率引起性能问题案例，且官方定位到问题也花了一些时间
