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

  • 时间:
  • 浏览:2
  • 来源:神彩大发幸运飞艇_彩神大发幸运飞艇官方

该何如出理 此大间题?我我觉得有并都在辦法 ,第一统统在将用户的实例内存降级,减小DROP期间的影响;第二统统将实例的版本升级到5.6版本;第三统统调整应用中的业务,优化Drop table的业务。最终采取了最简单的辦法 ,统统把实例的内存降低回原本的规格后,应用恢复正常。

双11原本用户都在进行大批量的弹性升级,期间有较多用户反馈,在弹性升级后性能经常跳出了大幅度的下降,其中由有一有一一4个用户有有一有一一4个RDS,有一有一一4个RDS进行了弹性升级,另外有一有一一4个RDS那末经常跳出弹性升级,结果弹性升级后的RDS反而经常跳出了性能下降,这让亲戚亲戚我们歌词 都都反思不得其解。RDS的弹性升级包括了两部分,一部分是磁盘容量的升级,另一部分是内存容量的升级(内存升级会一同升级数据库的连接数,CPU,IOPS),那末是什么由于由于了性能下降?

1.是都在弹性升级后,后端的DB性能提升,前端的流量增加,由于后端DB响应缓慢?

这是今年双11比较普遍的有一有一一4个大间题,用户升级完规格后性能反而经常跳出下降,统统原本你的应用中原本有少量的drop table,一同数据库的版本是MySQL 5.5,则建议升级到5.6版本(注意5.6版本开启了GTID,应用任务管理器池池中从不有create  temporary table的操作)。

#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  0x00000000001500939 in mysql_rm_table_no_locks(THD*, TABLE_LIST*)

#8  0x000000000015016dd 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 0x0000003bd61507851 in start_thread () from /lib64/libpthread.so.0

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

3.看后有非常简单的SQL也执行缓慢,排查主机算是处于资源瓶颈?

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

4.在排除了以上原本的情况报告后,在数据库连接经常跳出较多连接堆积的原本,进行一次pstack查看数据库中连接到底等待的图片 的图片 些什么:

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

原本现在现在结束的2015年双11,天猫以912亿的成交量再次打破去年的记录成为有一有一一4个奇迹,亲戚亲戚我们歌词 都都原本我还要知道,什么天猫的订单最后的出理 都在放上阿里云聚石塔的机房完成,从2012年现在现在结束,淘宝的ISV,商家就现在现在结束把亲戚亲戚我们歌词 都都的订单,CRM后台系统逐渐迁移到云上,最核心的数据库统统存放上RDS中。

通原本端的监控查看,数据库的QPS并那末显著的增加,统统RT却是增加了或多或少,统统此种情况报告排除。

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

2.是都在SQL的执行计划处于改变,由于数据库的性能降低?

通过监控显示,实例所在的物理主机的压力非常的低,都在主机的资源争抢由于的性能瓶颈,统统此种情况报告排除。

通过监控发现即使是普通的insert 说说也会经常跳出执行缓慢的情况报告,慢日志经常跳出了较多非常简单的SQL,统统此种情况报告排除。