国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

基于平臺工具的業(yè)務(wù)優(yōu)化

IT那活兒 / 792人閱讀
基于平臺工具的業(yè)務(wù)優(yōu)化
筆者所在公司因?yàn)橛信涮椎倪\(yùn)維產(chǎn)品工具，所以在實(shí)際工作中，當(dāng)遇到性能問題需要排查原因及優(yōu)化時(shí)，使用對應(yīng)的產(chǎn)工具基本就可定位處理大部分性能問題。總體上基于平臺工具可將處理流程分為兩部分：問題定位及針對性優(yōu)化。下面筆者就自己日常的問題定位和性能優(yōu)化過程予以分享，希望對讀者起到拋磚引玉之效。


問題定位



主要通過服務(wù)器性能、數(shù)據(jù)庫負(fù)載、Top事務(wù)三個(gè)維度進(jìn)行分析。其中，服務(wù)器性能分析可以對主機(jī)的CPU、內(nèi)存、SWAP、I/O等多個(gè)維度指標(biāo)進(jìn)行分析判斷，確認(rèn)問題后再通過相關(guān)日志（例如系統(tǒng)日志、OSW等）進(jìn)一步對問題排查；


數(shù)據(jù)庫負(fù)載分析可以對數(shù)據(jù)庫當(dāng)前的等待事件進(jìn)行歸類整理，通過性能圖表及Top會(huì)話可以很直觀的看出當(dāng)前數(shù)據(jù)庫存在的主要問題，并對引起數(shù)據(jù)庫負(fù)載升高的原因進(jìn)行排查。


Top事務(wù)可以對應(yīng)用程序/數(shù)據(jù)庫中響應(yīng)時(shí)間較長的事務(wù)進(jìn)行分析，并與應(yīng)用開發(fā)同事共同對引起事務(wù)響應(yīng)時(shí)間較長的原因進(jìn)行排查。




針對性優(yōu)化



根據(jù)精細(xì)化運(yùn)維平臺提供的SQL信息，如執(zhí)行時(shí)間、物理讀、相關(guān)對象統(tǒng)計(jì)等信息判斷SQL對數(shù)據(jù)庫產(chǎn)生的影響，對SQL性能及能否優(yōu)化做出初步的判斷。如果可以優(yōu)化，那么再根據(jù)執(zhí)行計(jì)劃、索引等信息對SQL語句采取相應(yīng)的優(yōu)化措施。




案例分享



下面主要通過3個(gè)實(shí)際工作中的案例，給大家介紹下借助精細(xì)化運(yùn)維平臺的優(yōu)化流程及解決方案，3個(gè)案例分別是：

  • 案例1、某系統(tǒng)單據(jù)查詢優(yōu)化

  • 案例2、某平臺ETLSQL優(yōu)化

  • 案例3、某系統(tǒng)檔案查詢優(yōu)化




某系統(tǒng)單據(jù)查詢優(yōu)化


問題現(xiàn)象及描述：

單據(jù)查詢是該系統(tǒng)的核心業(yè)務(wù)之一，該模塊自上線以后隨著數(shù)據(jù)量的不斷增大開始出現(xiàn)了性能問題，主要表現(xiàn)在：

1、模塊的響應(yīng)時(shí)間較長；


2、在業(yè)務(wù)高峰時(shí)段并發(fā)數(shù)較高時(shí)，系統(tǒng)CPU使用率飆升，進(jìn)而影響了其他模塊的正常運(yùn)行。


收到用戶反饋后，通過精細(xì)化平臺對應(yīng)用程序在業(yè)務(wù)高峰期時(shí)占用系統(tǒng)資源較多的事務(wù)進(jìn)行抓取，并對事務(wù)中的SQL語句進(jìn)行定位。


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



該模塊對應(yīng)的SQL為一條簡單查詢語句，視圖t1和視圖t2做關(guān)聯(lián)，從執(zhí)行計(jì)劃中可以看到，兩個(gè)視圖做了VIEWMERGE，ac表和au表關(guān)聯(lián)后，再去HASHt表。這里存在的問題是，每次au表模糊查詢返回的結(jié)果集數(shù)量非常少，但優(yōu)化器仍然將ID=5的Rows估算為1178（num_rows* 5%），進(jìn)而導(dǎo)致優(yōu)化器將NL的COST算多，導(dǎo)致T表（該表較大）進(jìn)行了全表掃描，而不是采用（acjoin au） NLT的連接方式，造成了性能瓶頸。


解決方案

由于優(yōu)化器對雙邊模糊查詢Rows估算的特殊性，導(dǎo)致在統(tǒng)計(jì)信息準(zhǔn)確的前提下對執(zhí)行計(jì)劃的選擇出現(xiàn)了偏差。在應(yīng)用側(cè)暫時(shí)無法修改代碼的前提下，針對該問題我們主要做了如下優(yōu)化措施：對模糊查詢相關(guān)表的統(tǒng)計(jì)信息刪除，使用動(dòng)態(tài)采樣。


優(yōu)化后，通過精細(xì)化運(yùn)維平臺可以看到，系統(tǒng)CPU資源得到了較大的緩解，查詢模塊的響應(yīng)時(shí)間也由長時(shí)間卡頓優(yōu)化至1秒內(nèi)返回結(jié)果，較大程度的提升了用戶的體驗(yàn)。




某平臺ETLSQL優(yōu)化



問題現(xiàn)象及描述

該平臺每月月初會(huì)有定時(shí)調(diào)度對上個(gè)月的少數(shù)異常數(shù)據(jù)進(jìn)行刪除，每次執(zhí)行時(shí)，系統(tǒng)性能問題較為明顯，主要表現(xiàn)在：

1、系統(tǒng)I/O資源占用明顯；


2、異常數(shù)據(jù)的清理模塊通常要執(zhí)行60小時(shí)左右，導(dǎo)致每月月初的前兩天該系統(tǒng)幾乎處于卡頓狀態(tài)。


下圖為該模塊執(zhí)行時(shí)，系統(tǒng)的I/O情況：


在語句執(zhí)行期間，我們通過精細(xì)化運(yùn)維平臺TopSQL模塊快速定位至相關(guān)SQL：


SQL詳情頁顯示，相關(guān)會(huì)話的活動(dòng)百分比占用了42%，SQL語句的平均邏輯讀、物理讀及耗費(fèi)的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);



該模塊對應(yīng)的是一條delete語句，相關(guān)SQL語句及執(zhí)行計(jì)劃顯示出兩點(diǎn)問題：

1、分區(qū)表沒有做分區(qū)裁剪，體現(xiàn)在ID=5的PARTITIONRANGEALL操作，該表按月分區(qū)，每月數(shù)據(jù)量為15G左右，目前有80個(gè)分區(qū)，全分區(qū)掃描嚴(yán)重影響了系統(tǒng)資源；


2、對大表的IX_CI1索引掃描次數(shù)較多（exits中g(shù)roupby having寫法造成的filter操作，且連接列machine_no基數(shù)較大）。


解決方案

了解用戶需求并定位至性能瓶頸后，我們對相關(guān)語句進(jìn)行了改寫，由于每月的異常數(shù)據(jù)量較少，因此我們采用了rowid的方式：

1、利用分析函數(shù)將異常數(shù)據(jù)提前計(jì)算，保存異常數(shù)據(jù)的rowid。


2、使用rowid驅(qū)動(dòng)主表進(jìn)行快速刪除。

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);


通過等價(jià)改寫后，整個(gè)模塊的性能開銷僅為對單個(gè)分區(qū)的掃描操作，性能得到大幅的提升，通過精細(xì)化運(yùn)維平臺顯示，優(yōu)化后，系統(tǒng)的性能得到了明顯的改善：

1、服務(wù)器的I/O資源得到了較大程度的緩解，iowait降至5%以內(nèi)；


2、數(shù)據(jù)庫的整體負(fù)載降低約60%，物理I/O降低約80%；


3、解決了模塊執(zhí)行時(shí)間過長的問題，經(jīng)過優(yōu)化該模塊的執(zhí)行時(shí)間降至20分鐘左右完成，優(yōu)化效果較為明顯。



某系統(tǒng)檔案查詢優(yōu)化



問題現(xiàn)象及描述

該模塊上線后，點(diǎn)擊查詢（由于總體返回的數(shù)據(jù)量不多，因此沒有設(shè)置過濾條件）按鈕長時(shí)間無響應(yīng)，系統(tǒng)CPU資源飆升，占用明顯。通過精細(xì)化運(yùn)維平臺顯示，在模塊執(zhí)行期間，系統(tǒng)CPU使用率在90%左右。


通過TopSQL模塊定位至相關(guān)語句，通過SQL詳情頁顯示，該SQL語句占用了近75%的系統(tǒng)資源，總邏輯讀達(dá)到3億，執(zhí)行時(shí)間已超過50小時(shí)，消耗了大量的DBTime，嚴(yán)重影響了數(shù)據(jù)庫性能。

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;



該模塊對應(yīng)的是一條查詢語句，結(jié)構(gòu)相對比較簡單，關(guān)聯(lián)后通過標(biāo)量計(jì)算對結(jié)果集進(jìn)行過濾，通過相關(guān)執(zhí)行計(jì)劃可以看到，標(biāo)量部分的WB與WR表關(guān)聯(lián)了多次，造成了性能瓶頸。


解決方案

確定了SQL語句存在的性能問題后，我們對相關(guān)SQL語句進(jìn)行了改寫，通常的優(yōu)化方案是對標(biāo)量部分進(jìn)行改寫，然后通過控制執(zhí)行計(jì)劃改變標(biāo)量的連接方式，提升性能：

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;


通過等價(jià)改寫后，整體的系統(tǒng)性能得到大幅提升，從精細(xì)化運(yùn)維平臺對比優(yōu)化前后的系統(tǒng)負(fù)載：

1、系統(tǒng)CPU由90%的使用率降至10%以內(nèi)，大幅降低了系統(tǒng)的整體負(fù)載；


2、系統(tǒng)邏輯讀由平均4K/s降至1.8k/s，有效的降低了I/O帶來的性能開銷；


3、相關(guān)模塊性能提升較為明顯，由長時(shí)間無響應(yīng)縮降至1秒左右完成；



總結(jié)


本篇文章主要給大家介紹了借助精細(xì)化運(yùn)維平臺輔助優(yōu)化的總體流程，當(dāng)遇到性能方面的問題時(shí)，我們可以借助現(xiàn)場已有平臺工具的各個(gè)分析模塊來快速的發(fā)現(xiàn)問題、分析定位并針對性的優(yōu)化，提高工作效率的同時(shí)也較大程度的縮短了利用傳統(tǒng)方式處理問題的時(shí)間，做到精細(xì)化運(yùn)維。

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

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

相關(guān)文章

  • <轉(zhuǎn)載>圖片流量節(jié)省60%：基于CDN的sharpP自適應(yīng)圖片技術(shù)實(shí)踐

    摘要：開啟驗(yàn)證上傳一張新圖片，使用手安卓版本訪問已支持域名的圖片，如果請求帶了，檢查返回圖片格式是否為如果舊的圖片未按預(yù)期返回，返回了或原圖可能是結(jié)點(diǎn)緩存，正常天后過期回源則會(huì)返回圖片。 對于圖片較多的網(wǎng)站，本文結(jié)合具體案例給出了如何基于CDN的sharpP自適應(yīng)圖片無痛接入方案，據(jù)統(tǒng)計(jì)效果可在原圖基礎(chǔ)上節(jié)省60%-75%的流量。作者：陳忱 出處：騰云閣文章 目前移動(dòng)端運(yùn)營素材大部分依賴圖...

    JerryZou 評論0 收藏0

  • “怎么做好云遷移”? 深藍(lán)云海資深架構(gòu)師給你答案

    摘要：基于云遷移的三個(gè)階段細(xì)分為八個(gè)主要步驟，評估階段主要包括項(xiàng)目啟動(dòng)現(xiàn)狀梳理以及應(yīng)用系統(tǒng)關(guān)聯(lián)關(guān)系分析三個(gè)步驟，設(shè)計(jì)階段包括云架構(gòu)優(yōu)化設(shè)計(jì)和云遷移方案設(shè)計(jì)，實(shí)施階段包括目標(biāo)架構(gòu)遷移演練及實(shí)施和試運(yùn)行三個(gè)步驟。 在云計(jì)算市場規(guī)模不斷擴(kuò)大的大背景下，云遷移的需求越來越大且面臨挑戰(zhàn)。云遷移不是一個(gè)遷移軟件工具，而是一種服務(wù)。前IBM資深架構(gòu)師姜亞杰從云遷移的三個(gè)階段、四個(gè)維度到八個(gè)步驟的方法，簡述...

    kk_miles 評論0 收藏0

  • 智能支付穩(wěn)定性測試實(shí)戰(zhàn)

    摘要：主要介紹了美團(tuán)智能支付業(yè)務(wù)在穩(wěn)定性方向遇到的挑戰(zhàn)，并重點(diǎn)介紹在穩(wěn)定性測試中的一些方法與實(shí)踐。其中，智能支付作為新擴(kuò)展的業(yè)務(wù)場景，去年也成為了美團(tuán)增速最快的業(yè)務(wù)之一。 本文根據(jù)美團(tuán)高級測試開發(fā)工程師勛偉在美團(tuán)第43期技術(shù)沙龍美團(tuán)金融千萬級交易系統(tǒng)質(zhì)量保障之路的演講整理而成。主要介紹了美團(tuán)智能支付業(yè)務(wù)在穩(wěn)定性方向遇到的挑戰(zhàn)，并重點(diǎn)介紹QA在穩(wěn)定性測試中的一些方法與實(shí)踐。 背景 美團(tuán)支付承載...

    The question 評論0 收藏0

  • 用AI創(chuàng)造AI，人工智能無代碼時(shí)代來臨

    摘要：無代碼時(shí)代來臨業(yè)務(wù)問題，而不只是機(jī)器學(xué)習(xí)我們希望企業(yè)可以用的時(shí)間來解決業(yè)務(wù)問題，而不是機(jī)器學(xué)習(xí)問題，談到整個(gè)人工智能和數(shù)據(jù)行業(yè)的未來發(fā)展時(shí)，黃一文這樣說道。 showImg(https://segmentfault.com/img/remote/1460000018912276); 瑪麗·雪萊在創(chuàng)作世界上第一部科幻小說《科學(xué)怪人》（又譯：弗蘭肯斯坦）的時(shí)候，恐怕沒法預(yù)見到在一個(gè)多世紀(jì)后...

    dreamans 評論0 收藏0

發(fā)表評論

0條評論

最新活動(dòng)
閱讀需要支付1元查看
<