背景图

一次生产问题查询与调优

最近在生产上查问题,各种问题,其实都是小问题。

首先来说一下背景吧,我们是蚂蚁金融云科技平台;蚂蚁的金融云平台是Paas层的技术,底层是阿里云的Iaas。这本来没啥特别的,区别就是阿里云是真技术,金融云这边是各类中间件,包括LDC、同城容灾、异地容灾。阿里云会在每台机器中安装天机的客户端,用于收集每台ECS机器的信息;而金融云不用去管每台机器,因为它的资源都是规划的,比如说这个租户需要哪些资源等等。

我们的系统在一个托管云,名字不重要了,在该云上租户之间是硬隔离的,租户之间的网络是不通的,我们团队是为银行做各类软件服务,所以会有很多租户的问题,金融云是Paas平台,那么我们就是基于Paas云的Saas平台。

好了聊了这么多,我们聊回问题;刚开始的时候报错的是一家租户,后来我和DBA查来查去都没有发现问题;找了很久终于在DBP同学的帮助下发现DBP的连接池大小配置被改了。之前配置都是800,谁会去该呢?这个问题很大哈。首先来解释一下什么是DBP,DBP是数据库代理层,实现了OB(MySQL)的协议,其实是各类数据库的协议,使用cobar实现分表分库的功能。熟悉MyCAt的人一定都知道Cobar是什么,这里就不多说了。反正就是连接被改了导致访问受限,tps达到50左右应用就报了数据库连接的问题。

对于这个问题,一开始我问了DBA关于连接数的问题,但是他没有看活跃连接数,如果看了就应该知道连接数不大于10,应为设置被改为了10。还有就是中间件有两台,两台机器的连接数都是10.实际连接数应该是20。这是实现,不多说,以后可以单独开篇博客来深入讲解下这里的实现。

这里我总结了一下经验

全线路查找在所难免,一定要了解你的上下游都在干嘛。

第二次另一个租户也出问题了,这个租户量比较大,200多tps,后来发现由于业务方流控做得不好,导致tps飙升至580左右,这个租户有6台4C8G的机器;我线下做过调试,单台机器tps可达100(线程数设置为16的时候,线程数为64的时候,tps50就报错了),由于线下环境的db和ots资源都很慢,所以线上的机器tps理论上一定大于100,6台600的tps应该是没问题的。

后来DBP的同学说连接没释放,问我有没有异常没commit或者rollback的情况,我很诧异,因为Mybatis都帮我处理好了呀,不该出这个问题才对。后来有研究DBPDataSourceDruidDataSource,看有没有直接getConnection的。但是搜了一圈也没发现。这个问题就这么僵着。但是我一直监控着数据,我发现随着时间的推移总会出现一些连接不释放的问题,而且在不停的累积。

后来我有了DBP机器的权限,于是我查了这台机器的日志,没发现特别的。就是觉得这台机器日志反映出的一些慢SQL是没有道理的,DBA反映很快;于是查了CPU发现,cpu使用率已经到达了65%,其中%system为25%左右,%user为40%左右,%idle为35%左右。后来发现上面显示2 CPU,赶紧cat /proc/cpuinfo,发现还真是2核的机器。

后来DBP的同学对我说4C8G的机器可达5000qps,那么2C4G可达2500qps,但是这个租户当时的量在3300qps左右,DBP有两台机器,所以理论上还是没有问题的,我仍然不知道为何连接池被占用。

直到今天,我查了下ISV的流量,发现10s一个循环,5s有流量,5s没啥流量,这就意味着之前我们认为的3300qps计算有误,因为那是分钟级的,换成秒级6600tps,完全超了。这也许就是连接池泄漏的根本原因。

永远不要被已知事实迷惑,分钟级的东西不要相信,还是要关注秒级的tps

后来发现ISV的同学是使用MQ做流控,而这种规律的不均匀流量就是MQ引起的;只要推动他们去修改一下。

有些事情你确实需要去了解一下

后来又发现了部分MQ发送失败的问题,因为系统有自愈重试的能力,也就没有太在意。但是架构组的同学还是找了消息中间件的同学跟进解决。后来发现是我们的日志打印太多,出现了太大的磁盘IO的await。但是发MQ消息是网络能力,与磁盘无关。这个也许就是中间件自己做了啥事情,这个就不得而知了。

刨根问底才能找到最根本的问题,如果因为影响不大而忽视,可能永远也发现不了问题。
看起来不相关的两件事,也许存在极大的关联性,发现的时候的确会吓你一跳。

解决的方式就是使用日志的异步化打印功能。

0%