成人无码视频,亚洲精品久久久久av无码,午夜精品久久久久久毛片,亚洲 中文字幕 日韩 无码

資訊專欄INFORMATION COLUMN

性能故障之dual調(diào)用風(fēng)暴案例分享

IT那活兒 / 1919人閱讀
性能故障之dual調(diào)用風(fēng)暴案例分享
看兄弟們的總結(jié)輸出,不僅讓我想起奮殺一線的時光,每一個老司機(jī)都有屬于自己的移動硬盤和老師;每個老司機(jī)內(nèi)心都有讓自己記憶終身的性能故障;每一個老司機(jī)都是燒不死的鳥兒。但,所有的經(jīng)歷回頭看,都是那么的讓人熱淚盈眶。為什么回憶往事總是讓我們熱淚盈眶,因為我對這份職業(yè)愛的深沉。讓我們把時間撥回到2017年......

近期某省渠道應(yīng)用的簽到送流量業(yè)務(wù)出現(xiàn)了嚴(yán)重的業(yè)務(wù)超時情況,與此同時該渠道Tuxedo中間件的維護(hù)人員在該活動的業(yè)務(wù)高峰期,也接收到了大量涉及業(yè)務(wù)辦理服務(wù)的積壓告警短信。


通過對積壓的Tuxedo服務(wù)執(zhí)行效率進(jìn)行統(tǒng)計,發(fā)現(xiàn)該服務(wù)在業(yè)務(wù)高峰期時單筆調(diào)用的服務(wù)執(zhí)行總耗時已經(jīng)達(dá)到13.4732s。


中間件維護(hù)人員在對該服務(wù)進(jìn)行實時truss過程中,未發(fā)現(xiàn)明顯的執(zhí)行過程等待現(xiàn)象,但經(jīng)過對該服務(wù)單筆調(diào)用記錄的數(shù)據(jù)進(jìn)行分析和統(tǒng)計后,發(fā)現(xiàn)在一次調(diào)用過程中,該服務(wù)對數(shù)據(jù)庫讀、寫的次數(shù)累計已經(jīng)超過了14000次。



同時在truss過程中,我們發(fā)現(xiàn)每次的read5write5對象分別為讀、寫CRM庫。


于是馬上接入CRM庫進(jìn)行分析,跟蹤積壓服務(wù)在數(shù)據(jù)庫執(zhí)行情況。通過剖析主要發(fā)現(xiàn)該服務(wù)發(fā)起的session存在大量的librarycache: mutex X爭用,且都在特定的sql上(sql_id:afqzw543rcu2d)。


另外該sql30min內(nèi)累計執(zhí)行3.8kw次,與此同時主機(jī)Runq隊列高居不下,Cpu資源耗盡。


通過剖析該sql,發(fā)現(xiàn)該sql主要是利用dual表進(jìn)行date轉(zhuǎn)換。


由此可發(fā)現(xiàn),本次服務(wù)積壓主要與此sql有關(guān),但該服務(wù)模塊上線較早,且近期沒有新的變更,那么此次的問題是否和sql調(diào)用量增加有關(guān)系?


帶著此疑問,我們對此sql的調(diào)用量做了對比分析。


分析發(fā)現(xiàn)2116點(diǎn)到9點(diǎn)30分總執(zhí)行次數(shù)只有5000萬次左右,3206點(diǎn)到9點(diǎn)30分總共執(zhí)行了1.1億次,327日,6點(diǎn)到9點(diǎn)30分,總共執(zhí)行了4.01億次,差不多增長了4倍。所以從數(shù)據(jù)上分析,該SQL的執(zhí)行次數(shù)是一個不斷增長的趨勢;


同時發(fā)現(xiàn),隨著問題sql執(zhí)行次數(shù)的增加,librarycache: mutex X等待次數(shù)也跟著同比增加,進(jìn)而使得主機(jī)Runq隊列劇增,Cpu資源耗盡。


那么要解決該問題,就要控制該sql執(zhí)行頻率。通過同應(yīng)用側(cè)溝通,最終通過修改業(yè)務(wù)邏輯,在數(shù)據(jù)庫中屏蔽該sql。


優(yōu)化后對服務(wù)調(diào)用量及平均響應(yīng)時長進(jìn)行了監(jiān)控和數(shù)據(jù)搜集。


對比發(fā)現(xiàn),優(yōu)化后服務(wù)執(zhí)行效率提升顯著,且穩(wěn)定,無服務(wù)隊列積壓情況出現(xiàn)。下圖為上線前后服務(wù)執(zhí)行效率對比曲線圖:


此案例中我們發(fā)現(xiàn)在應(yīng)用代碼中使用selectxxx from dual, SQL雖然簡單,且單次執(zhí)行性能優(yōu)良,但如高頻率的執(zhí)行,則會有資源高消耗的隱患。


因此建議避免在數(shù)據(jù)庫內(nèi)部進(jìn)行與數(shù)據(jù)庫無關(guān)的處理;且日期以及字符串等相關(guān)處理各種程序語言(C、Java)都提供了豐富的函數(shù)庫可使用,本地化處理不僅可以避免與數(shù)據(jù)庫的交互,更可以降低數(shù)據(jù)庫的負(fù)載,提高服務(wù)性能。


獨(dú)坐思往昔,愁絕淚盈襟。下回見。

文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址:http://m.hztianpu.com/yun/130209.html

相關(guān)文章

  • zabbix報警發(fā)送填坑

    摘要:報警阻塞,發(fā)送效率低下這種情況下,報警是根據(jù)用戶一個個用戶發(fā)送。效果極大的簡化了報警配置,僅配置了兩個。發(fā)送效率提高,對于一個報警,無論發(fā)送人數(shù)多少,都只需要觸發(fā)執(zhí)行一次腳本。 通常zabbix告警主要可以通過三種方式 1. 自帶的直接調(diào)用消息接口服務(wù) 2. 執(zhí)行自定義腳本發(fā)送消息 3. 通過send remote commend 的方式通過執(zhí)行腳本發(fā)送 2和3的本質(zhì)都只通過zabb...

    yankeys 評論0 收藏0
  • 有效運(yùn)維的 on-call 機(jī)制

    摘要:如何有效處理緊急事件驅(qū)動的工作,成為特別是運(yùn)維主管運(yùn)維工作的關(guān)鍵。通知到位和及時響應(yīng)。機(jī)器學(xué)習(xí)領(lǐng)域是未來的重要發(fā)展方向,目前我們還在摸索中。機(jī)器學(xué)習(xí)告警合并事件單的處理如果告警量很大,告警后續(xù)處理和跟蹤往往會依賴于外部團(tuán)隊部門外或公司外。 編者按]本文作者為陳伯龍,云告警平臺[OneAlert創(chuàng)始人,著《云計算與OpenStack》,在IT運(yùn)營管理、云計算方面從業(yè)10多年。 正文 互聯(lián)...

    binaryTree 評論0 收藏0
  • 有效運(yùn)維的 on-call 機(jī)制

    摘要:如何有效處理緊急事件驅(qū)動的工作,成為特別是運(yùn)維主管運(yùn)維工作的關(guān)鍵。通知到位和及時響應(yīng)。機(jī)器學(xué)習(xí)領(lǐng)域是未來的重要發(fā)展方向,目前我們還在摸索中。機(jī)器學(xué)習(xí)告警合并事件單的處理如果告警量很大,告警后續(xù)處理和跟蹤往往會依賴于外部團(tuán)隊部門外或公司外。 編者按]本文作者為陳伯龍,云告警平臺[OneAlert創(chuàng)始人,著《云計算與OpenStack》,在IT運(yùn)營管理、云計算方面從業(yè)10多年。 正文 互聯(lián)...

    DirtyMind 評論0 收藏0
  • 測試管理項目軟件測試風(fēng)險管理實踐

    摘要:在軟件測試活動中,作為一名測試人員有沒有遇到過這樣的場景,在測試一個特性或者制定一份測試方案時,往往會想著進(jìn)行簡單測試做簡單設(shè)計,認(rèn)為這個場景出現(xiàn)的概率太低,幾乎不可能會存在,不測了實際應(yīng)用時不可能會有這么大的用戶量, ...

    用戶84 評論0 收藏0

發(fā)表評論

0條評論

IT那活兒

|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<