RDS彈性公升級後效能反而下降的排查

剛剛結束的2023年雙11，天貓以912億的成交量再次打破去年的記錄成為乙個奇蹟，大家可能不知道，這些天貓的訂單最後的處理都是放在阿里雲聚石塔的機房完成，從2023年開始，**的isv，商家就開始把他們的訂單，crm後台系統逐漸遷移到雲上，最核心的資料庫就是存放在rds中。

雙11之前使用者都會進行大批量的彈性公升級，期間有較多使用者反饋，在彈性公升級後效能出現了大幅度的下降，其中乙個使用者有兩個rds，乙個rds進行了彈性公升級，另外乙個rds沒有彈性公升級，結果彈性公升級後的rds反而出現了效能下降，這讓我們反思不得其解。rds的彈性公升級包括了兩部分，一部分是磁碟容量的公升級，另一部分是記憶體容量的公升級（記憶體公升級會同時公升級資料庫的連線數，cpu，iops），那麼是什麼原因導致了效能下降？

1.是不是彈性公升級後，後端的db效能提公升，前端的流量增加，導致後端db響應緩慢？

通過後端的監控檢視，資料庫的qps並沒有顯著的增加，但是rt卻是增加了許多，所以此種情況排除。

2.是不是sql的執行計畫發生改變，導致資料庫的效能降低？

通過監控發現即使是普通的insert 語句也會出現執行緩慢的情況，慢日誌出現了較多非常簡單的sql，所以此種情況排除。

3.看到有非常簡單的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 0x0000000000600939 in mysql_rm_table_no_locks(thd*, table_list*)

#8 0x00000000006016dd 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*)

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

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

看到了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的業務。最終採取了最簡單的辦法，就是把例項的記憶體降低回原來的規格後，應用恢復正常。

這是今年雙11比較普遍的乙個問題，使用者公升級完規格後效能反而出現下降，所以如果你的應用中如果有大量的drop table，同時資料庫的版本是mysql 5.5，則建議公升級到5.6版本（注意5.6版本開啟了gtid，應用程式中不要有create temporary table的操作）。

RDS彈性公升級後效能反而下降的排查

RDS彈性公升級後效能反而下降的案例

npm公升級後報錯

element ui公升級後報錯

RDS彈性公升級後效能反而下降的排查

RDS彈性公升級後效能反而下降的案例

npm公升級後報錯

element ui公升級後報錯

相關推薦