注意:以下文档只适用于TOP接口,请谨慎使用!

文档中心 > 聚石塔

RDS连接数过高优化

更新时间:2015/09/18 访问次数:32214

连接数过高告警

如果出现连接数报警的时候,可以通过show processlist查看数据库中正在运行的连接。一般sql执行慢或者某个sql持有锁导致其他sql等待,两种情况都会引发会话堆积产生报警。解决方法:
       1.
优化慢查询可以解决问题;
       2.
对于由于持有锁的sql 导致连接堆积,则需要根据业务是否允许 ,kill掉持有锁的会话;
       3.
如果连接数用满,并且不自动释放,可以在RDS控制台重启一下实例。

4. 高并发的情况下,少使用长连接

5. 设置一个短的超时时间,让短连接尽快的自动关闭:wait_timeout

6. 使用了myisam存储引擎的表,如果该表上面的查询没有返回的话,会堵塞该表的写入,从而导致连接堆积将表的引擎转为innodb

INNODBMyisam RDS的内存配置innodbinnodb_buffer_pool_size,Myisamkey_cache配置32k .主机断电,crashMyisam表容易出现索引坏叶,需要手工repair修复索引Myisam存储引擎的,表备份时候会被全局锁住,导致无法写入数据

修改引擎的语句:

alter table *** engine=innodb;Mysq

连接通常是一个请求占用一个连接,如果该请求(updateinsertdeleteselect)长时间没有执行完毕,则会造成连接的堆积,迅速的消耗完数据库的连接数,这个时候工程师就要登录数据库进行排序,看看到底是那些sql 占用了连接;

问题排查步骤:

1 、查看实例配置:

可登录RDS控制台“详情与配置”查看实例额定链接数,我们假设最高支持1500个链接

2、 查看当前的连接数:

1)可登录RDS控制台“性能监控”查看实例当前链接数。

2)或者登录数据库查询当前连接,可以使用同步帐号或者用户的业务帐号登录数据库,执行show processlist

[root@r41d05036.xy2.aliyun.com ~]# mysql -uroot -h127.0.0.1 -P3020 -e "show processlist"|wc -l

1262

可以看到该实例已经有1262 个连接

3、排查是什么动作占用了这些连接:

[root@r41d05036.xy2.aliyun.com ~]# myql -uroot -h127.0.0.1 -P3018 -e "show full processlist">/tmp/1.log

root@r14d11038.dg.aliyun.com # more /tmp/1.log

615083 my_db 223.4.49.212:54115 my_db Query 100 Sending data

INSERT INTO tmp_orders_modify (oid, tid, seller_id, `status`, gmt_create, gmt_modified)

SELECT oid, tid, seller_id, `status`, gmt_create, gmt_modified

FROM sys_info.orders WHERE

gmt_modified < NAME_CONST('v_last',_binary'2012-12-24 10:33:00' COLLATE 'binary') AN

D gmt_modified >= NAME_CONST('v_curr',_binary'2012-12-24 10:32:00' COLLATE 'binary')

621564 my_db 223.4.49.212:46596 my_db Query 3890 sorting result

insert into tmp_trades(sid, d, h, tc, tm, tp, ic, new_tp, old_tp)

select a.seller_id as sid,

…………..

from orders_1 as a where seller_id =1 and is_detail = '1'

and created < date_format('2012-12-24 10:35:00', '%Y-%m-%d %H:00:00')

and gmt_create < date_format('2012-12-24 10:40:00', '%Y-%m-%d %H:%i:00')

and gmt_create >= date_format('2012-12-24 10:35:00', '%Y-%m-%d%H:%i:00')

group by d, h

order by d

……………….此处省略其他sql

4、分析连接占用的原因:

可以看到数据库中有长时间没有执行完成的sql,一直占用着连接没有释放,而应用的请求一直持续不断的涌入数据库,这个时候数据库的连接很快就被使用完;所以这个时候需要排查为什么这些sql 为什么长时间没有执行完毕,是索引没有创建好,还是sql执行耗时严重。

第一条sql

INSERT INTO tmp_orders_modify (oid, tid, seller_id, `status`, gmt_create, gmt_modified)

SELECT oid, tid, seller_id, `status`, gmt_create, gmt_modified

FROM sys_info.orders WHERE

gmt_modified < NAME_CONST('v_last',_binary'2012-12-24 10:33:00' COLLATE 'binary') AN

D gmt_modified >= NAME_CONST('v_curr',_binary'2012-12-24 10:32:00' COLLATE 'binary')

是用户从sys_info 数据库中拉取订单到自己的业务库中那个,但是在orders 表上没有gmt_modified 的索引,导致了全表扫描;(更加详尽的排查方法可以参考:为什么我的RDS慢了);

第二条sql

看到这条sql 正在进行sorting 排序,为什么导致sql 长时间sorting,通常情况下为排序的结果集太大导致排序不能在内存中完成,需要到磁盘上排序,进而导致了性能的下降;解决的办法就是降低排序的结果集,常用的手段是利用索引的有序性,消除排序,或者建立适当的索引减小结果集;我们可以看到第二条sql 的排序字段非常的复杂,但是我们可以看到查询的时间范围是很短,只有5 分钟的时间间隔,这个时候就可以在gmt_create上创建一个索引,过滤掉大部分的记录:

Alter tale order_1 add index ind_order_gmt_create(gmt_create)

(该用户对orders 进行了分表,大概有50 多张分表需要添加gmt_create 字段的索引);

5、经过上面两步的优化后,用户实例恢复正常:io 情况和connection 情况,可再次登陆RDS控制台查看连接数。

 

 

 

FAQ

关于此文档暂时还没有FAQ
返回
顶部