每一次犯错都是成长的机会
早上8:40左右,地铁上,在跟小伙伴聊天,接到电话“是不是服务出问题了?” 第一个反应,不可能吧。昨天又没有上线,前天刚优化过,并且又没有收到告警。
这个电话刚挂,又有一个电话打来,说“XXX系统有异常,看看你这边有没有问题”。 可能有问题了!! 不一定是我们服务的问题,但要澄清一下,给出解决问题的方向。 刷群,看到一个报错信息:
xxx业务异常访问customers接口异常:status 503 reading ICustomerServiceApi#customers(CustomerReq); content: up
503 Service Unavailable 这种报错在上线发版时会出现,原因是由于请求被强行中断,即常说的“断流”。因为OpenApi服务最近一天没有任何改动,这种情况下,外部原因的可能性比较大,譬如网络问题。
打电话找到离电脑最近的同学,通报情况并开始排查。发现是数据库连接不够用了
### Error querying database. Cause: org.springframework.jdbc.CannotGetJdbcConnectionException: Failed to obtain JDBC Connection; nested exception is com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis 60000, active 150, maxActive 150, creating 0, runningSqlCount 150 : SELECT
奇怪,前天才将应用中数据库连接池的maxActive从100升级到150。 出现这种错误,在严重耦合DB的服务面前,除了重启应用来重新初始化数据库连接池外,没有其它更好的办法了。
确定开始重新部署后,继续刷群,收集对锁定问题有帮忙的信息。 公司其它团队的小伙伴真是给力:
应用重启完成后。服务恢复正常
pod:Pod是Kubernetes调度的最小单元。简单理解,一个Pod相当于一个逻辑主机,每个pod都有自己的ip地址,pod内的容器共享相同的ip和端口空间。在实际的使用中,一个应用的进程是运行在Pod的容器中。 生产环境,一个Pod只运行一个业务进程是最佳实践。 一个Pod可以包含一个或多个容器。容器是基于镜像创建的,即容器中的进程依赖于镜像中的文件,这里的文件包括进程运行所需要的可执行文件,依赖软件,库文件,配置文件等。镜像是文件, 容器是进程。
如何停止MySql上正在运行的任务 解决方案(类似于linux服务器杀进程):
bash KILL [CONNECTION | QUERY] thread_id
或select concat( ' KILL ' ,id, ' ; ' ) from information>_schema.processlist where user = ' root ' ;
+------------------------+
| concat('KILL ',id,';')
+------------------------+
| KILL 3101;
| KILL 2946;
+------------------------+
2 rows in set (0.00 sec)
目前有数据库中间件把上面的过程封装起来,提供了更高效的工具。譬如将没有绑定变量的SQL作为模板,生成唯一的指纹,然后设置规则则,阻止指定指纹的SQL语句执行。这个机制只能处理新的异常SQL。历史的,只能手动kill了
更改后的规则:
1.2 为什么周例会上没有通报这个系统有慢SQL 这个数据库有3个系统在用。然后就不知道写谁,然后就...
这个慢SQL之前已经识别到,并排期准备改了。 关联的接口流量并不大,不可能。即使流量变大了,涉及到的表数据量并不大,即使全表扫描,也不可能导致MySql cpu 100%吧! 后来翻了代码,这个慢SQL是2018年的一位同学写的。老的没问题,是因为的老的是高配 4.1 流量是否变大 变大了。 有一个前台系统将流量切过来了。12.14 19:00切过来,19:00到23:00共1484次请求,12.13号同时段共2次请求 12.15 8:10到8:40共3510次请求,12.13号同时段共1次请求 迁移原因:记一次中台建设的过程及心得
4.2 扫描的数据行多不多 不多。SQL执行的情况如下:
4.3 为什么CPU会100% 没有走索引是一个待优化点,真正的问题是:当前的数据库实例的cpu对md5函数比较敏感,抽一个慢Sql连接执行3次,CPU利用率直接上升到6.57%:
趋势图:
4.4 12.14 19:00-12.15 08:00期间CPU为什么没有100% 19:50已经出现尖刺了,期间出现瞬时峰值100%:
尖刺时间段内的慢SQL:
4.5 为什么早上8点期间有持续的100% 流量持续增多。新接入流量的并发数增加了2倍,并且持续一段时间。 12.14 19:50 出现尖刺时的并发数是4。当然也不能忽视前面几秒积累的慢查询:
12.15 08:22左右 MySql cpu利用率100%时的新增流量的并发最大值为8。当然加上其它两个系统在这个时间点也是使用高峰期,还有之前积累的慢查询:
4.6 为什么相同的调用频繁出现 调用方进行了超时重试
存在一个消耗CPU资源且有一个关键字段不能走索引的慢SQL。因为之前流量比较低,消耗的资源不足以让MySql CPU持续100%。
12.14 19:00 前台一个系统将流量切过来,晚上用的人较少,其它两个系统用的人也少,虽在12.14 19:50出现瞬时100%,但MySql整体稳定。 12.15 08:22开始新切入的流量从1增加到8,并持续稳定在并发数8左右。使用这个数据库的其它两个系统,也有慢SQL进来,导致慢SQL执行更加慢。还有一个不能忽视:前台请求时的超时重试。如果一个接口耗时超过的一定的时间,譬如3s,调用端就会再次发起相同的请求。 这种场景,相当于把流量放大几倍,会进一步加剧服务提供方的资源紧张的情况。
短期:
长期:
系统稳定性无小事,一出问题就是大事。