原創(chuàng)|行業(yè)資訊|編輯:陳俊吉|2016-10-19 09:39:03.000|閱讀 1836 次
概述:熱點是數據庫應用中常見的問題之一。在系統(tǒng)并發(fā)量比較小的時候,通常感覺不到它的存在,而當并發(fā)請求急劇增加的時候,響應時間被大大地拉長,極端情況系統(tǒng)掛起。
# 界面/圖表報表/文檔/IDE等千款熱門軟控件火熱銷售中 >>
相關鏈接:
熱點是應用中常見的問題之一。在系統(tǒng)并發(fā)量比較小的時候,通常感覺不到它的存在,而當并發(fā)請求急劇增加的時候,響應時間被大大地拉長,極端情況系統(tǒng)掛起。
熱點可能在記錄上,可能在數據或索引頁面上,也可能在其它對象上,比如緩沖池、程序包,甚至到數據庫之下的操作系統(tǒng)層。常見的是前兩種。
典型的記錄熱點場景有:應用維護流水號,或者余額控制,相關信息保存在用戶表的記錄中,每次交易都作UPDATE操作。UPDATE會在記錄上加獨占鎖,會堵塞其它應用對同一條記錄的UPDATE操作,這個獨占鎖要等整個事務提交或回滾后才會釋放。假設這個事務執(zhí)行時間是10毫秒,那么這個系統(tǒng)能支撐的最大交易吞吐量是100筆/秒,更多的交易請求進來將處于等待狀態(tài)。
如何能夠知道系統(tǒng)存在這種熱點問題? 如果做數據庫監(jiān)測的話,可關注并發(fā)應用數、應用等鎖次數和平均鎖等待時間,
如果等鎖次數及等待時間隨應用并發(fā)增加而增加的話,很有可能存在這種問題。
也有可能你的系統(tǒng)負載一直不高,看不到上述變化,又怎么能知道系統(tǒng)有這種風險?
在DB2中可用命令db2pd –db -tcbstats獲取表相關的操作信息,在“TCB Table Stats:”段內容中有表上發(fā)生UPDATE的次數,用次數除以表的記錄數,可計算出平均每行記錄被更新的次數,如果某表上這個指標較高,意味著可能有熱點記錄問題。當然這個辦法不一定很準確,比如表中有很多條記錄,其中一條或幾條被更新的次數遠高于其它,便不能用這種方法識別出來,更準確的方法是捕捉到每一條SQL語句,分析UPDATE操作指向的記錄。 預先知道隱含問題,就可以改進系統(tǒng),避免出現類似“雙十一”或“秒殺”活動對系統(tǒng)帶來的沖擊。
改進方法就是去除熱點或分散熱點。比如可用數據庫的SEQUENCE幫助產生流水號,數據庫的SEQUENCE可在內存一次產生多個流水號,個數由CACHE指定,并發(fā)高的系統(tǒng)可加大CACHE;分散熱點是將一條記錄拆成多條記錄,根據傳入參數更新對應記錄。
除記錄熱點外,還有可能出現數據頁面或索引頁面熱點。比如多條記錄保存在同一個數據頁面,雖然并發(fā)應用更新的是不同記錄,但數據庫內部在更新數據頁面內容時會加LATCH以避免內容錯亂,用一般的數據庫監(jiān)控可能不能發(fā)現此類問題,使用db2pd -latch有可能看到沖突。解決辦法是減少同一個數據頁面內保存的記錄數,比如(ALTERTABLE myTable PCTFREE 90; REORG TABLE myTable),重組之后每個頁面只用10%的空間保存記錄。當然你也可能有其它方法達到此目的。
索引頁面的熱點主要發(fā)生在索引字段內容一直增加或減少的情況,比如時間戳或流水號上的索引,每次INSERT進來的記錄,其相關索引內容都落在最后的索引頁面中,這在單服務器的數據庫中可能沒太大問題,但在集群環(huán)境中,這個熱點問題會被放大。DB2中有一種RANDOM INDEX可規(guī)避這個問題,比如:CREATEINDEX myIdx ON myTable (seqno RANDOM);RANDOMINDEX是基于變換后的內容構建索引,因此它失去了原來的順序,避免了索引頁面熱點,但只適合“=”條件查詢,BETWEEN及“>”之類查詢條件不能從這種索引中得到原來的好處。
如果能在設計開發(fā)階段就考慮到些熱點問題,避開它,就更好了。
如果您碰到其它一些熱點問題,也可以拿出來跟大家分享一下。
詳情請咨詢!
客服熱線:023-66090381
本站文章除注明轉載外,均為本站原創(chuàng)或翻譯。歡迎任何形式的轉載,但請務必注明出處、不得修改原文相關鏈接,如果存在內容上的異議請郵件反饋至chenjj@fc6vip.cn