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

  • 时间:
  • 浏览:0

该何如正确处理此问提报告 ?嘴笨 有五种依据,第一何如让在将用户的实例内存降级,减小DROP期间的影响;第二何如让将实例的版本升级到5.6版本;第三何如让调整应用中的业务,优化Drop table的业务。最终采取了最简单的依据,何如让把实例的内存降低回何如让的规格后,应用恢复正常。

通过监控显示,实例所在的物理主机的压力非常的低,后会主机的资源争抢由于的性能瓶颈,就是我 此种具体情况排除。

通过监控发现即使是普通的insert 一句话也会总出 执行缓慢的具体情况,慢日志总出 了较多非常简单的SQL,就是我 此种具体情况排除。

2.是后会SQL的执行计划位于改变,由于数据库的性能降低?

4.在排除了以上不可能 的具体情况后,在数据库连接总出 较多连接堆积的已经 ,进行一次pstack查看数据库中连接到底在等候些哪些地方:

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

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

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

通已经 端的监控查看,数据库的QPS并那么显著的增加,何如让RT却是增加了某些,就是我 此种具体情况排除。

这是今年双11比较普遍的一八个 问提报告 ,用户升级完规格后性能反而总出 下降,就是我 不可能 你的应用中不可能 有血块的drop table,一块儿数据库的版本是MySQL 5.5,则建议升级到5.6版本(注意5.6版本开启了GTID,应用守护系统进程中何必 有create  temporary table的操作)。

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

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

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

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

双11已经 用户后会进行大批量的弹性升级,期间有较多用户反馈,在弹性升级后性能总出 了大幅度的下降,其中由一八个 用户八个 RDS,一八个 RDS进行了弹性升级,另外一八个 RDS那么总出 弹性升级,结果弹性升级后的RDS反而总出 了性能下降,这我能 们歌词 儿反思不得其解。RDS的弹性升级包括了两累积,一累积是磁盘容量的升级,另一累积是内存容量的升级(内存升级会一块儿升级数据库的连接数,CPU,IOPS),那么是哪些地方由于由于了性能下降?

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

已经 开始英语 的2015年双11,天猫以912亿的成交量再次打破去年的记录成为一八个 奇迹,当当.我 儿不可能 他不知道,哪些地方地方天猫的订单最后的正确处理后会放到去阿里云聚石塔的机房完成,从2012年开始英语 ,淘宝的ISV,商家就开始英语 把当当.我 的订单,CRM后台系统逐渐迁移到云上,最核心的数据库何如让存放到去RDS中。