All in？跑步入場(chǎng)？清倉？為了這些動(dòng)作，Ta們?cè)?.....
國(guó)慶節(jié)前的幾天A股大漲，很多資深股民紛紛狂曬朋友圈，“All in！”、“跑步入場(chǎng)”、“再漲30%，我就回本了”、“ ?；?，速歸，記住不要賣掉電動(dòng)車！”、“3點(diǎn)收盤太早啦，強(qiáng)烈要求國(guó)慶節(jié)加班”。老股民解套在望，新股民躍躍欲試。交易量和用戶活躍度都在急劇增加，證券公司的系統(tǒng)性能成為了保障交易順利進(jìn)行的關(guān)鍵。終于，大家期待的證券公司“加班”，真的來啦！
國(guó)慶假期期間，為了保障高并發(fā)下的系統(tǒng)穩(wěn)定運(yùn)行，中亦科技配合一些證券公司客戶加班進(jìn)行了壓力測(cè)試，其中一個(gè)客戶遇到了意想不到的瓶頸，可能導(dǎo)致系統(tǒng)運(yùn)行緩慢，影響交易。我們今天就一起來看看這個(gè)“新鮮”的案例！
某證券客戶對(duì)系統(tǒng)進(jìn)行性能壓測(cè)，結(jié)果系統(tǒng)運(yùn)行緩慢，大量會(huì)話積壓，無法達(dá)到交易目標(biāo)。這一問題亟需優(yōu)化處理，以確保在股市熱潮中系統(tǒng)能夠穩(wěn)定運(yùn)行。
收集問題時(shí)段AWR報(bào)告，可以看到系統(tǒng)的等待事件如下：
從系統(tǒng)的負(fù)載來看，系統(tǒng)中硬解析的并發(fā)量不算大，每秒161.7多左右的：
因主要在解析階段，在AWR報(bào)告中就并不進(jìn)一步觀察SQL語句執(zhí)行階段的問題。AWR報(bào)告顯示，系統(tǒng)異常等待主要是`latch:row cache objects`的等待，即出現(xiàn)在row cache層面的爭(zhēng)用。在AWR報(bào)告中，對(duì)于row cache部分的統(tǒng)計(jì)如下：
可以看到在dc_tablespaces和 dc_users 層面出現(xiàn)大量訪問請(qǐng)求。壓測(cè)階段通過對(duì)系統(tǒng)做hanganalyze，可以看到如下相關(guān)信息：
分析阻塞鏈上的各會(huì)話的short stack，可以看到：
在short stack中，可以看到此時(shí)進(jìn)程處于硬解析的過程中，為了計(jì)算hash join的成本，需要用ktatminextsz函數(shù)從row cache中查找臨時(shí)表空間的最小擴(kuò)展的大小，作為計(jì)算因子。我們知道要想訪問row cache，首先要拿到shared pool里的latch: row cache object，以得到相應(yīng)row cache的地址。當(dāng)有大量進(jìn)程需要訪問dc_tablespace這個(gè)row cache object時(shí)，首先會(huì)在latch: row cache object發(fā)生爭(zhēng)用。由于這個(gè)爭(zhēng)用引發(fā)的等待，硬解析時(shí)間會(huì)變長(zhǎng)，從而引發(fā)cursor: pin S wait on X的等待。
針對(duì)這一問題，我們考慮了以下三個(gè)可能的解決方案：
1、減少CBO對(duì)hash join的路徑嘗試。（顯然可能性不大）
2、減少硬解析。(每秒161次不算過分)
3、提高獲取臨時(shí)表空間最小擴(kuò)展的性能。（查下有沒有相應(yīng)的bug或者enhance）
針對(duì)該現(xiàn)象，先核查相關(guān)MOS文檔，可以查到對(duì)應(yīng)的文檔，描述類似情況：對(duì)應(yīng)的文檔號(hào)為2189126.1：
產(chǎn)生該問題的原因?yàn)閎ug引發(fā)：
具體查看對(duì)應(yīng)的bug 13902396 如下：
可以看到，根據(jù)bug 13902396 的描述，產(chǎn)生大量對(duì)于dc_users和dc_tablespaces的row cache訪問是因?yàn)?，在調(diào)用ktatminextsz函數(shù)時(shí)，高頻的訪問數(shù)據(jù)字典獲取”minimum extent
size for the users temporary tablespace”這個(gè)信息，事實(shí)上通過該bug的修復(fù)，在于直接設(shè)定返回一個(gè)值，而不再去數(shù)據(jù)字典中查找，避免出現(xiàn)latch爭(zhēng)用；從實(shí)際情況來看，臨時(shí)表空間的最小擴(kuò)展基本是個(gè)固定的值，通過設(shè)備事件直接返回這個(gè)值，是可行的，幾乎不會(huì)存在什么隱患。我們只需要從ts$中查出這個(gè)最小擴(kuò)展的大小，然通過event設(shè)置一下，就可以繞過對(duì)latch: row cache object及dc_tablespace、dc_user的訪問。在修復(fù)該bug后，還需要設(shè)置事件來進(jìn)行優(yōu)化處理。
四、最終選擇
經(jīng)過綜合分析，我們最終選擇了第三個(gè)方案——提高獲取臨時(shí)表空間最小擴(kuò)展的性能。具體實(shí)施步驟如下：
針對(duì)客戶數(shù)據(jù)庫版本（11.2.0.4版本），為客戶打上補(bǔ)丁13902396，修復(fù)了高頻訪問數(shù)據(jù)字典的問題。
通過設(shè)置事件45053，繞過對(duì)`latch: row cache object`及`dc_tablespace`、`dc_user`的訪問，直接返回臨時(shí)表空間的最小擴(kuò)展大小。
通過這一方案，系統(tǒng)性能得到了顯著提升，解決了硬解析導(dǎo)致的性能瓶頸問題。在股市熱潮中，證券公司的系統(tǒng)性能至關(guān)重要。技術(shù)優(yōu)化不僅是提升系統(tǒng)性能的關(guān)鍵，更是抓住市場(chǎng)機(jī)遇的重要保障。希望這篇文章能為大家提供有價(jià)值的參考。如果大家有相關(guān)的技術(shù)問題，歡迎留言聯(lián)系我們。
