RDS弹性升级后性能反而下降的案例

  • 时间:
  • 浏览:0
  • 来源:uu直播快3平台

通过监控发现即使是普通的insert 句子也会老出执行缓慢的清况 ,慢日志老出了较多非常简单的SQL,所以此种清况 排除。

1.有无弹性升级后,后端的DB性能提升,前端的流量增加,愿因 后端DB响应缓慢?

双11这麼 用户有无进行大批量的弹性升级,期间有较多用户反馈,在弹性升级后性能老出了大幅度的下降,其中由另另3个用户有另另3个RDS,另另3个RDS进行了弹性升级,另外另另3个RDS这麼老出弹性升级,结果弹性升级后的RDS反而老出了性能下降,这让.我 反思不得其解。RDS的弹性升级包括了两每段,一每段是磁盘容量的升级,另一每段是内存容量的升级(内存升级会同時 升级数据库的连接数,CPU,IOPS),这麼是哪此愿因 愿因 了性能下降?

3.看过有非常简单的SQL也执行缓慢,排查主机有无指在资源瓶颈?

通这麼 端的监控查看,数据库的QPS并这麼显著的增加,否则RT却是增加了许多,所以此种清况 排除。

2.有无SQL的执行计划指在改变,愿因 数据库的性能降低?

#0  0x00000000008d3fd9 in buf_LRU_invalidate_tablespace ()

#1  0x0000000000904ef6 in fil_delete_tablespace ()

#2  0x00000000008627cf in row_drop_table_for_mysql ()

#3  0x000000000084d64e in ha_innobase::delete_table(char const*) ()

#4  0x0000000000554368 in rm_temporary_table(handlerton*, char*) ()

#5  0x0000000000556ea2 in close_temporary(TABLE*, bool, bool) ()

#6  0x000000000055a878 in drop_temporary_table(THD*, TABLE_LIST*, bool*)

#7  0x000000000060 0939 in mysql_rm_table_no_locks(THD*, TABLE_LIST*)

#8  0x000000000060 16dd in mysql_rm_table(THD*, TABLE_LIST*, char, char) ()

#9  0x0000000000599b35 in mysql_execute_command(THD*) ()

#10 0x0000000000788629 in sp_instr_stmt::exec_core(THD*, unsigned int*) ()

#11 0x000000000078d267 in sp_lex_keeper::reset_lex_and_exec_core(THD*, unsigned int*, bool, sp_instr*) ()

#12 0x000000000078d724 in sp_instr_stmt::execute(THD*, unsigned int*) ()

#13 0x000000000078b1b3 in sp_head::execute(THD*, bool) ()

#14 0x000000000078c587 in sp_head::execute_procedure(THD*, List<Item>*)

#15 0x0000000000597f84 in mysql_execute_command(THD*) ()

#16 0x000000000059bed4 in mysql_parse(THD*, char*,  Parser_state*) ()

#17 0x000000000059deac in dispatch_command(enum_server_command, )

#18 0x0000000000641b8d in do_handle_one_connection(THD*) ()

#19 0x0000000000641cdc in handle_one_connection ()

#20 0x0000003bd660 7851 in start_thread () from /lib64/libpthread.so.0

#21 0x0000003bd64e767d in clone () from /lib64/libc.so.6

这是今年双11比较普遍的另另3个哪此的问题图片,用户升级完规格后性能反而老出下降,所以否则你的应用中否则有大量的drop table,同時 数据库的版本是MySQL 5.5,则建议升级到5.6版本(注意5.6版本开启了GTID,应用守护进程中并非有create  temporary table的操作)。

http://bugs.mysql.com/bug.php?id=51325

http://bugs.mysql.com/bug.php?id=64284

通过监控显示,实例所在的物理主机的压力非常的低,有无主机的资源争抢愿因 的性能瓶颈,所以此种清况 排除。

这麼 现在开始的2015年双11,天猫以912亿的成交量再次打破去年的记录成为另另3个奇迹,.我 否则不知道,哪此天猫的订单最后的正确处理有无放入阿里云聚石塔的机房完成,从2012年现在开始,淘宝的ISV,商家就现在开始把.我 的订单,CRM后台系统逐渐迁移到云上,最核心的数据库所以存放入RDS中。

看过了buf_LRU_invalidate_tablespace 这个函数后,我我真是就豁然开朗了,用户业务中频繁的drop table,在5.5版本DROP TABLE操作会对innodb的整个buffer pool的LRU链进行两次扫描(DROP期间的扫描操作会持有buf_pool::mutex,愿因 整个数据库hang主),否则内存很大,则会愿因 阻塞时间加长(5.6版本改进只扫描flush list,则会大大降低影响),相关的bug列表可不让能参考:

该怎么可不都可以正确处理此哪此的问题图片?我我真是有这个方式,第一所以在将用户的实例内存降级,减小DROP期间的影响;第二所以将实例的版本升级到5.6版本;第三所以调整应用中的业务,优化Drop table的业务。最终采取了最简单的方式,所以把实例的内存降低回这麼 的规格后,应用恢复正常。

4.在排除了以上否则的清况 后,在数据库连接老出较多连接堆积的这麼 ,进行一次pstack查看数据库中连接到底等待歌曲歌曲些哪此: