福利一区二区三区视频在线观看,又粗又猛又黄又爽无遮挡免费的,日韩精品无码视频一区二区蜜桃,日本一区二区三区中文字幕不卡,欧洲韩国野花视频一

立即咨詢
2024.10.09 |
All in?跑步入場?清倉?為了這些動作,Ta們在......
是時候放下手中的“大盤”,看看技術啦~

國慶節(jié)前的幾天A股大漲,很多資深股民紛紛狂曬朋友圈,“All in!”、“跑步入場”、“再漲30%,我就回本了”、“ ?;兀贇w,記住不要賣掉電動車!”、“3點收盤太早啦,強烈要求國慶節(jié)加班”。老股民解套在望,新股民躍躍欲試。交易量和用戶活躍度都在急劇增加,證券公司的系統(tǒng)性能成為了保障交易順利進行的關鍵。終于,大家期待的證券公司“加班”,真的來啦!


640.png



國慶假期期間,為了保障高并發(fā)下的系統(tǒng)穩(wěn)定運行,中亦科技配合一些證券公司客戶加班進行了壓力測試,其中一個客戶遇到了意想不到的瓶頸,可能導致系統(tǒng)運行緩慢,影響交易。我們今天就一起來看看這個“新鮮”的案例!

一、問題描述



某證券客戶對系統(tǒng)進行性能壓測,結果系統(tǒng)運行緩慢,大量會話積壓,無法達到交易目標。這一問題亟需優(yōu)化處理,以確保在股市熱潮中系統(tǒng)能夠穩(wěn)定運行。

二、問題分析



1. 問題現(xiàn)象分析
收集問題時段AWR報告,可以看到系統(tǒng)的等待事件如下:
640 (1).png





從系統(tǒng)的負載來看,系統(tǒng)中硬解析的并發(fā)量不算大,每秒161.7多左右的:
640 (2).png





數(shù)據(jù)庫時間模型上看,大量時間花在(硬)解析上:
640 (3).png




因主要在解析階段,在AWR報告中就并不進一步觀察SQL語句執(zhí)行階段的問題。

2. 異常等待事件分析
AWR報告顯示,系統(tǒng)異常等待主要是`latch:row cache objects`的等待,即出現(xiàn)在row cache層面的爭用。
在AWR報告中,對于row cache部分的統(tǒng)計如下:
640 (4).png



可以看到在dc_tablespaces和 dc_users 層面出現(xiàn)大量訪問請求。
壓測階段通過對系統(tǒng)做hanganalyze,可以看到如下相關信息:
640 (5).png



分析阻塞鏈上的各會話的short stack,可以看到:
640 (6).png

640 (7).png



在short stack中,可以看到此時進程處于硬解析的過程中,為了計算hash join的成本,需要用ktatminextsz函數(shù)從row cache中查找臨時表空間的最小擴展的大小,作為計算因子。我們知道要想訪問row cache,首先要拿到shared pool里的latch: row cache object,以得到相應row cache的地址。當有大量進程需要訪問dc_tablespace這個row cache object時,首先會在latch: row cache object發(fā)生爭用。由于這個爭用引發(fā)的等待,硬解析時間會變長,從而引發(fā)cursor: pin S wait on X的等待。

三、解決方案



針對這一問題,我們考慮了以下三個可能的解決方案:


1、減少CBO對hash join的路徑嘗試。(顯然可能性不大)

2、減少硬解析。(每秒161次不算過分)

3、提高獲取臨時表空間最小擴展的性能。(查下有沒有相應的bug或者enhance)


針對該現(xiàn)象,先核查相關MOS文檔,可以查到對應的文檔,描述類似情況:

對應的文檔號為2189126.1:

640 (8).png



產(chǎn)生該問題的原因為bug引發(fā):

640 (9).png



具體查看對應的bug 13902396 如下:


640 (9).png


640 (10).png

640 (11).png

640 (12).png

可以看到,根據(jù)bug 13902396 的描述,產(chǎn)生大量對于dc_users和dc_tablespaces的row cache訪問是因為,在調(diào)用ktatminextsz函數(shù)時,高頻的訪問數(shù)據(jù)字典獲取”minimum extent

size for the users temporary tablespace”這個信息,事實上通過該bug的修復,在于直接設定返回一個值,而不再去數(shù)據(jù)字典中查找,避免出現(xiàn)latch爭用;
從實際情況來看,臨時表空間的最小擴展基本是個固定的值,通過設備事件直接返回這個值,是可行的,幾乎不會存在什么隱患。我們只需要從ts$中查出這個最小擴展的大小,然通過event設置一下,就可以繞過對latch: row cache object及dc_tablespace、dc_user的訪問。

在修復該bug后,還需要設置事件來進行優(yōu)化處理。

640 (13).png




四、最終選擇




經(jīng)過綜合分析,我們最終選擇了第三個方案——提高獲取臨時表空間最小擴展的性能。具體實施步驟如下:


1. 修復bug

針對客戶數(shù)據(jù)庫版本(11.2.0.4版本),為客戶打上補丁13902396,修復了高頻訪問數(shù)據(jù)字典的問題。


2. 設置事件

通過設置事件45053,繞過對`latch: row cache object`及`dc_tablespace`、`dc_user`的訪問,直接返回臨時表空間的最小擴展大小。

640 (14).png


通過這一方案,系統(tǒng)性能得到了顯著提升,解決了硬解析導致的性能瓶頸問題。
在股市熱潮中,證券公司的系統(tǒng)性能至關重要。技術優(yōu)化不僅是提升系統(tǒng)性能的關鍵,更是抓住市場機遇的重要保障。希望這篇文章能為大家提供有價值的參考。如果大家有相關的技術問題,歡迎留言聯(lián)系我們。


相關推薦
助力IT企業(yè)信創(chuàng)服務,和企業(yè)一起走向成功
立即領取企業(yè)福利 預約您的專屬顧問
400-1037-370