建站
咨詢
售后
建站咨詢
新聞中心
?優(yōu)化這個(gè)話題是很多朋友感興趣的，今天就再聊聊。很多人說(shuō)給系統(tǒng)做優(yōu)化就像醫(yī)生治病，用藥的君臣佐輔，下藥的順序都不能差了。我不懂中醫(yī)之術(shù)，因此不好類比。不過(guò)我懂炒菜，就用炒菜的道理來(lái)聊聊優(yōu)化這項(xiàng)工作吧。
讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來(lái)自于我們對(duì)這個(gè)行業(yè)的熱愛(ài)。我們立志把好的技術(shù)通過(guò)有效、簡(jiǎn)單的方式提供給客戶，將通過(guò)不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：空間域名、虛擬空間、營(yíng)銷軟件、網(wǎng)站建設(shè)、橫山網(wǎng)站維護(hù)、網(wǎng)站推廣。
要想讓一道菜好吃，炒菜的主料配料選擇與配比十分關(guān)鍵，只有主料一味未免單調(diào)，而選擇比較搶戲的配料也不合適，會(huì)把主料的味道給沖了，讓菜的味道變得比較怪異。合適的主配料搭配和配比是一道菜好吃不好吃的基礎(chǔ)。
針對(duì)這個(gè)Load Profile我們可以看出系統(tǒng)中存在很多高負(fù)載的點(diǎn)，每秒redo超過(guò)9MB，邏輯讀632萬(wàn)+，物理讀高達(dá)6.4萬(wàn)+/秒，一小時(shí)內(nèi)的讀寫IOPS高達(dá)1.8萬(wàn)+，讀IO吞吐量500MB+/秒，寫IO吞吐量15MB/秒，每秒事務(wù)數(shù)100+，每秒執(zhí)行數(shù)接近5000。針對(duì)這個(gè)負(fù)載文件，我們能給它找出食材配料表嗎？
也許有些朋友還比較謹(jǐn)慎，還需要繼續(xù)看看等待事件和命中率的情況再下結(jié)論。從命中率上好像也看不出啥來(lái)，都是較高負(fù)載的系統(tǒng)應(yīng)該有的命中率情況。唯一低點(diǎn)的是library Cache的命中率和軟解析的比例。不過(guò)從解析占用的CPU資源上看，問(wèn)題似乎也不算太大。
從等待事件上看，好像除了DB CPU外，都是gc方面的問(wèn)題，單塊讀等待只占3.4%，而且平均延時(shí)只有1毫秒，說(shuō)明存儲(chǔ)性能不錯(cuò)。確實(shí)，本系統(tǒng)的主要數(shù)據(jù)都在閃存盤上。
從等待事件的分類統(tǒng)計(jì)上看，DB CPU占了近一半，cluster排第二位，占了26.9%。似乎解決掉這兩個(gè)問(wèn)題，系統(tǒng)的主要問(wèn)題就都解決了。不過(guò)到這里我們還是無(wú)法做出很好的判斷，必須繼續(xù)分析。
這時(shí)候我們需要繼續(xù)查看CPU的情況，因?yàn)閺闹饕录峡矗珻PU占比較大。從這個(gè)報(bào)告上看，LOAD居然高達(dá)500+，這對(duì)于128核，256線程的7、8年前采購(gòu)的服務(wù)器來(lái)說(shuō)，有點(diǎn)高了。
從OSW的數(shù)據(jù)上，我們也驗(yàn)證了CPU負(fù)載很高的問(wèn)題。這套系統(tǒng)是問(wèn)題十分嚴(yán)重的，因此現(xiàn)象表現(xiàn)其實(shí)是十分明顯的，很容易找到我們需要的食材。CPU使用率過(guò)高、IO負(fù)載過(guò)高、REDO量過(guò)大、集群等待比較嚴(yán)重、共享池存在一定問(wèn)題。這些都是目前系統(tǒng)存在問(wèn)題的關(guān)鍵，也就是我們要享用的食材。
下一步就是怎么烹調(diào)這道菜了，煎炒烹炸，蒸煮煲湯，哪種方式更適合這些食材呢？這就是我們要制定的優(yōu)化策略了。從這個(gè)系統(tǒng)上來(lái)看，有經(jīng)驗(yàn)的DBA一定會(huì)選擇先降低CPU的使用率，因?yàn)槿绱舜蟮腎O量，后端存儲(chǔ)還撐得住，沒(méi)有性能明顯下降的趨勢(shì)，在CPU與IO的選擇中，首先會(huì)選擇降CPU為主的做法。一旦確定了CPU優(yōu)先的測(cè)了，那么在第一階段的優(yōu)化中，REDO的問(wèn)題也不需要過(guò)多的考慮了，雖然平均每秒有9MB+的REDO量，以經(jīng)驗(yàn)來(lái)看，全閃的SAN存儲(chǔ)是沒(méi)有任何問(wèn)題的。
選定了烹飪方法之后，就要考慮烹制的細(xì)節(jié)了。先熗鍋還是先爆鍋，用葷油還是素油，加蔥姜還是大蒜？這種選擇奠定了采的基本味道，因此不得不重視。因?yàn)檫@套系統(tǒng)的優(yōu)化需求十分緊急，因此找出一些邏輯讀較高，CPU使用量較高的SQL，看看能不能通過(guò)添加索引，糾正執(zhí)行計(jì)劃等方法把CPU降一降。給后續(xù)的全面優(yōu)化爭(zhēng)取出一定的時(shí)間。
這個(gè)系統(tǒng)中的RAC GC的問(wèn)題也很嚴(yán)重，要想分析如何優(yōu)化GC，首先我們需要分析RAC的相關(guān)指標(biāo)。
從RAC的相關(guān)指標(biāo)上看，除了流量大一些以外，其他指標(biāo)都正常，不算太差，說(shuō)明GC問(wèn)題不是系統(tǒng)性的，而僅僅是部分SQL不優(yōu)化引發(fā)的，這種問(wèn)題解決起來(lái)比較容易。在消息上，Ksxp隊(duì)列上的延時(shí)比較大，indirect sent的比例偏高了一點(diǎn)。這些都是和流量較大有關(guān)的。因此降低RAC INTERCONNECT的流量應(yīng)該是解決這個(gè)問(wèn)題的比較穩(wěn)妥的方法。雖然說(shuō)優(yōu)化CPU使用率高的SQL有助于降低RAC流量。不過(guò)我們?nèi)绻軌蜥槍?duì)性的解決問(wèn)題，才會(huì)有更為明顯的效果。
這些TOP SEGMENT相關(guān)的SQL語(yǔ)句是我們本次優(yōu)化的重點(diǎn)，在這里我們發(fā)現(xiàn)了一張消息表。有200GB+，其中的數(shù)據(jù)可以刪除清理。如果能夠完成這個(gè)操作，可以大大降低RAC通訊流量。
經(jīng)過(guò)這樣一個(gè)個(gè)的分析，我們就基本上能夠確定第一階段的工作方案了。通過(guò)第一階段，首先解決目前最為緊迫的問(wèn)題，讓系統(tǒng)恢復(fù)可用。然后給我們留出足夠多的時(shí)間來(lái)做精細(xì)化的全面優(yōu)化。通過(guò)全面優(yōu)化，讓系統(tǒng)煥然一新。?
當(dāng)前名稱：我們一起用炒菜的道理來(lái)聊聊優(yōu)化這項(xiàng)工作
URL分享：http://m.fisionsoft.com.cn/article/cdioooh.html
