資訊專欄INFORMATION COLUMN
主要通過服務器性能、數據庫負載、Top事務三個維度進行分析。其中，服務器性能分析可以對主機的CPU、內存、SWAP、I/O等多個維度指標進行分析判斷，確認問題后再通過相關日志（例如系統日志、OSW等）進一步對問題排查；
數據庫負載分析可以對數據庫當前的等待事件進行歸類整理，通過性能圖表及Top會話可以很直觀的看出當前數據庫存在的主要問題，并對引起數據庫負載升高的原因進行排查。
Top事務可以對應用程序/數據庫中響應時間較長的事務進行分析，并與應用開發同事共同對引起事務響應時間較長的原因進行排查。
根據精細化運維平臺提供的SQL信息，如執行時間、物理讀、相關對象統計等信息判斷SQL對數據庫產生的影響，對SQL性能及能否優化做出初步的判斷。如果可以優化，那么再根據執行計劃、索引等信息對SQL語句采取相應的優化措施。
下面主要通過3個實際工作中的案例，給大家介紹下借助精細化運維平臺的優化流程及解決方案，3個案例分別是：
案例1、某系統單據查詢優化
案例2、某平臺ETLSQL優化
案例3、某系統檔案查詢優化
單據查詢是該系統的核心業務之一，該模塊自上線以后隨著數據量的不斷增大開始出現了性能問題，主要表現在：
1、模塊的響應時間較長；
2、在業務高峰時段并發數較高時，系統CPU使用率飆升，進而影響了其他模塊的正常運行。
收到用戶反饋后，通過精細化平臺對應用程序在業務高峰期時占用系統資源較多的事務進行抓取，并對事務中的SQL語句進行定位。
selectt1.* from(select * fromau leftjoin ac onac.ct_number = au.agent_code whereau.repair_no like %XXXX%) t1, (selectform_id, max(task_id), max(audit_node) fromt whereform_type = 01 groupby form_id) t2 wheret1.id = t2.form_id orderby t1.repair_no |
該模塊對應的SQL為一條簡單查詢語句，視圖t1和視圖t2做關聯，從執行計劃中可以看到，兩個視圖做了VIEWMERGE，ac表和au表關聯后，再去HASHt表。這里存在的問題是，每次au表模糊查詢返回的結果集數量非常少，但優化器仍然將ID=5的Rows估算為1178（num_rows* 5%），進而導致優化器將NL的COST算多，導致T表（該表較大）進行了全表掃描，而不是采用（acjoin au） NLT的連接方式，造成了性能瓶頸。
由于優化器對雙邊模糊查詢Rows估算的特殊性，導致在統計信息準確的前提下對執行計劃的選擇出現了偏差。在應用側暫時無法修改代碼的前提下，針對該問題我們主要做了如下優化措施：對模糊查詢相關表的統計信息刪除，使用動態采樣。
優化后，通過精細化運維平臺可以看到，系統CPU資源得到了較大的緩解，查詢模塊的響應時間也由長時間卡頓優化至1秒內返回結果，較大程度的提升了用戶的體驗。
該平臺每月月初會有定時調度對上個月的少數異常數據進行刪除，每次執行時，系統性能問題較為明顯，主要表現在：
1、系統I/O資源占用明顯；
2、異常數據的清理模塊通常要執行60小時左右，導致每月月初的前兩天該系統幾乎處于卡頓狀態。
下圖為該模塊執行時，系統的I/O情況：
在語句執行期間，我們通過精細化運維平臺TopSQL模塊快速定位至相關SQL：
SQL詳情頁顯示，相關會話的活動百分比占用了42%，SQL語句的平均邏輯讀、物理讀及耗費的DBTime等均占用較大。
deletefrom ci o whereexists (select t.machine_no, t.plat_flag fromci t wheret.machine_no = o.machine_no andt.plat_flag = o.plat_flag andt.month_time = 2019-02 groupby t.machine_no, t.plat_flag havingcount(*) > 1) andexists (select 1 froms_info s wheres.area_no = substr(o.machine_no, 1, 7) ando.cname <> s.cname); |
該模塊對應的是一條delete語句，相關SQL語句及執行計劃顯示出兩點問題：
1、分區表沒有做分區裁剪，體現在ID=5的PARTITIONRANGEALL操作，該表按月分區，每月數據量為15G左右，目前有80個分區，全分區掃描嚴重影響了系統資源；
2、對大表的IX_CI1索引掃描次數較多（exits中groupby having寫法造成的filter操作，且連接列machine_no基數較大）。
了解用戶需求并定位至性能瓶頸后，我們對相關語句進行了改寫，由于每月的異常數據量較少，因此我們采用了rowid的方式：
1、利用分析函數將異常數據提前計算，保存異常數據的rowid。
2、使用rowid驅動主表進行快速刪除。
delete/*+ use_nl(c) */ fromci c whererowid in (select /*+ full(t) leading(s) use_hash(t) */ t.rowid from(select t.cname, t.machine_no, count(*)over(partition by t.machine_no, t.plat_flag) cnt fromci t wheret.month_time = 2019-02) t, s_infos wheret.cnt> 1 andsubstr(t.machine_no, 1, 7) = s.area_no andt.cname <> s.cname); |
通過等價改寫后，整個模塊的性能開銷僅為對單個分區的掃描操作，性能得到大幅的提升，通過精細化運維平臺顯示，優化后，系統的性能得到了明顯的改善：
1、服務器的I/O資源得到了較大程度的緩解，iowait降至5%以內；
2、數據庫的整體負載降低約60%，物理I/O降低約80%；
3、解決了模塊執行時間過長的問題，經過優化該模塊的執行時間降至20分鐘左右完成，優化效果較為明顯。
該模塊上線后，點擊查詢（由于總體返回的數據量不多，因此沒有設置過濾條件）按鈕長時間無響應，系統CPU資源飆升，占用明顯。通過精細化運維平臺顯示，在模塊執行期間，系統CPU使用率在90%左右。
通過TopSQL模塊定位至相關語句，通過SQL詳情頁顯示，該SQL語句占用了近75%的系統資源，總邏輯讀達到3億，執行時間已超過50小時，消耗了大量的DBTime，嚴重影響了數據庫性能。
selectws.id, wa.ct_number, ms.business fromws leftjoin wa onwa.ct_number = ws.ct_number leftjoin ms onms.station_code = ws.st_number wherews.status = 有效 and(select count(1) fromwb leftjoin wr onwr.wp_no = wb.wp_no wherewr.is_urgent = 1 andwr.service_no = ws.st_number) < ws.pg_number; |
該模塊對應的是一條查詢語句，結構相對比較簡單，關聯后通過標量計算對結果集進行過濾，通過相關執行計劃可以看到，標量部分的WB與WR表關聯了多次，造成了性能瓶頸。
確定了SQL語句存在的性能問題后，我們對相關SQL語句進行了改寫，通常的優化方案是對標量部分進行改寫，然后通過控制執行計劃改變標量的連接方式，提升性能：
selectws.id, wa.ct_number, ms.business fromws leftjoin wa onwa.ct_number = ws.ct_number leftjoin ms onms.station_code = ws.st_number leftjoin (selectwr.service_no, count(1) cnt fromwb leftjoin wr onwr.wp_no = wb.wp_no wherewr.is_urgent = 1 groupby wr.service_no)cc on(cc.service_no = ws.st_number) wherews.status = 有效 andnvl(cc.cnt,0)< ws.pg_number; |
通過等價改寫后，整體的系統性能得到大幅提升，從精細化運維平臺對比優化前后的系統負載：
1、系統CPU由90%的使用率降至10%以內，大幅降低了系統的整體負載；
2、系統邏輯讀由平均4K/s降至1.8k/s，有效的降低了I/O帶來的性能開銷；
3、相關模塊性能提升較為明顯，由長時間無響應縮降至1秒左右完成；
本篇文章主要給大家介紹了借助精細化運維平臺輔助優化的總體流程，當遇到性能方面的問題時，我們可以借助現場已有平臺工具的各個分析模塊來快速的發現問題、分析定位并針對性的優化，提高工作效率的同時也較大程度的縮短了利用傳統方式處理問題的時間，做到精細化運維。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/130203.html
摘要：開啟驗證上傳一張新圖片，使用手安卓版本訪問已支持域名的圖片，如果請求帶了，檢查返回圖片格式是否為如果舊的圖片未按預期返回，返回了或原圖可能是結點緩存，正常天后過期回源則會返回圖片。 對于圖片較多的網站，本文結合具體案例給出了如何基于CDN的sharpP自適應圖片無痛接入方案，據統計效果可在原圖基礎上節省60%-75%的流量。作者：陳忱 出處：騰云閣文章 目前移動端運營素材大部分依賴圖...
摘要：基于云遷移的三個階段細分為八個主要步驟，評估階段主要包括項目啟動現狀梳理以及應用系統關聯關系分析三個步驟，設計階段包括云架構優化設計和云遷移方案設計，實施階段包括目標架構遷移演練及實施和試運行三個步驟。 在云計算市場規模不斷擴大的大背景下，云遷移的需求越來越大且面臨挑戰。云遷移不是一個遷移軟件工具，而是一種服務。前IBM資深架構師姜亞杰從云遷移的三個階段、四個維度到八個步驟的方法，簡述...
摘要：主要介紹了美團智能支付業務在穩定性方向遇到的挑戰，并重點介紹在穩定性測試中的一些方法與實踐。其中，智能支付作為新擴展的業務場景，去年也成為了美團增速最快的業務之一。 本文根據美團高級測試開發工程師勛偉在美團第43期技術沙龍美團金融千萬級交易系統質量保障之路的演講整理而成。主要介紹了美團智能支付業務在穩定性方向遇到的挑戰，并重點介紹QA在穩定性測試中的一些方法與實踐。 背景 美團支付承載...
摘要：無代碼時代來臨業務問題，而不只是機器學習我們希望企業可以用的時間來解決業務問題，而不是機器學習問題，談到整個人工智能和數據行業的未來發展時，黃一文這樣說道。 showImg(https://segmentfault.com/img/remote/1460000018912276); 瑪麗·雪萊在創作世界上第一部科幻小說《科學怪人》（又譯：弗蘭肯斯坦）的時候，恐怕沒法預見到在一個多世紀后...
閱讀 1346·2023-01-11 13:20
閱讀 1684·2023-01-11 13:20
閱讀 1132·2023-01-11 13:20
閱讀 1858·2023-01-11 13:20
閱讀 4100·2023-01-11 13:20
閱讀 2704·2023-01-11 13:20
閱讀 1385·2023-01-11 13:20
閱讀 3597·2023-01-11 13:20
