丨案例帶寬消耗以及swap下

2020-02-24性能測試實戰(zhàn)30 進入課28:34大小上一篇文章我主要分析了帶寬消耗，今天，我們來看一下分析的第二和第三階段Swap分析和數(shù)據(jù)庫分析Swap的原理和對TPS的影前面有一個扣，是說swap多的問題。要理解swap為什么是黃的，得先知道什swap。我先畫個簡易的示意圖這里先解釋一下，對于一個Linux系統(tǒng)來說，如果配置并開啟了swap分區(qū)，那么默swappiness數(shù)是60當上圖中已用內(nèi)存超過40%（100%-60%）時，系統(tǒng)就會主動切換swap和activefile比例swappiness在reclaim時候生效的，而reclaim式同時有兩個動作：1相關(guān)內(nèi)存進行回收；2anon存交換到swap區(qū)所以swapiness值越大，swap分區(qū)就用得越多。我們看到這里配置了一個內(nèi)存為8G右，已經(jīng)使用了7G了，swappiness置30%。也就是說當內(nèi)存使用超過8Gx(100%-30%)=5.6G時，就會使用swap分區(qū)通過看到現(xiàn)在只有145M物理內(nèi)存剩余，可用內(nèi)存也只有254M也就是說現(xiàn)在只有145（剩余物理內(nèi)存大?。?7821（總物理內(nèi)存大小）≈1.9%的空閑內(nèi)存，這個比例已經(jīng)遠遠小于swappiness的30%了。也就是說這系統(tǒng)早就開始用swap所以上面圖中的swap黃也是很合理的嘍！下面我們就針對應(yīng)用服務(wù)器的swap來看是不是可優(yōu)化。所有人都知道，當swap的時候，性能肯定會下降，所以在我的測試過程中，一般我都建議把swap直接關(guān)掉測試性能，有人說這樣有什么問題？那就是swap，讓不常用的對象直接占用物理內(nèi)存，如果物理內(nèi)存不夠用，就把對象刪了，后面再創(chuàng)建，這時會增加的是majorfault，那就增加好了，反正是要性能差的。說得如此硬氣，那在生產(chǎn)中怎么辦呢？開還是關(guān)？有人覺得關(guān)了心里有安穩(wěn)，有人覺得開著心里會安穩(wěn)。而一個議關(guān)掉。開著它，也只是心里上的安慰，不會有S處理能力上的提升。瓶頸分析定既然知道了上面的大概原理。對一個運行Tomcat用的服務(wù)器來說，那肯定是要先檢查一下JVM設(shè)置為多大。先執(zhí)行ps命令，看一下Java進程吧。關(guān)鍵參數(shù)如下代代1JAVA_OPTS="$JAVA_OPTS-server-Xms2048M-Xmx8192m-XX:PermSize=256M-JVM是1.8.0_65這個參數(shù)配置有很大的問題。物理內(nèi)存只有8G，JVMheap配8G，這讓其他的東西怎么玩得起來？并且JDK是1.8了，配置permsize是又為啥呢？雖說有多個地方配置不合理，但是我們也得要知道一下應(yīng)該配置多少是合理的看參數(shù)的時候，JMX也配置上了，那就用工具來看首先來看一下系統(tǒng)資源。先看一下系統(tǒng)資源在壓力下隊列已經(jīng)出現(xiàn)，CS2萬多，in2萬多，說多不多。我們可以先放I/O沒什 壓力，swap也一直有值，我們要解決的就是它us：sy接近2：1，這個是不良信號，記在心里，后面再說。其次再看下JVM的情況：CPU用在應(yīng)用上的時間60%，GC沒耗什么時間，并且從堆的回收能力上來看，比較正常，只是只用到了3G左右，這里有必要給8G嗎？ 從這個JVM態(tài)上來看，它完全用不到8G。在這種狀態(tài)下，還有另一個Tomat，并且另一個Tomcat中也沒有配置-Xmx-Xms參數(shù)，當沒有配置時，默認-Xmx是物理內(nèi)存的1/4。再加上thread用的，物理內(nèi)存很快就會消耗到5.6G，所以swap飄黃也是吻合的。優(yōu)化結(jié)首先，我們把JVM配置成最簡，JVM設(shè)置為4G代代1JAVA_OPTS="$JAVA_OPTS-server-Xms4096M-perm區(qū)在1.8里都沒有了，這幾個參數(shù)也沒啥用。在我的習慣中，MaxNewSize也是先各部分配置為多大，都沒有定數(shù)，要通過測試看需要而我們現(xiàn)在最重要的是先把性能調(diào)整上去，再考慮這些細節(jié)內(nèi)容。這樣JVM是為了把物理內(nèi)存使用率低下來，先不修改swapiness的比例是為了看下結(jié)果，如果用不到swap就不再調(diào)了，如果還是用了swap，再來調(diào)它。當我們把JVM修改了之后，再執(zhí)行起來場景?？吹絻?nèi)CPU使用率相對前面沒有什么變化，但是堆4G只用到了1.5G，可見這個堆連4G都用不還記得我們要解決的是什么問題吧？swap飄黃了從這可以看到Swap不 了！CPU占用70%左右。說明現(xiàn)在available的內(nèi)應(yīng)用服務(wù)器系統(tǒng)資源vmstat如下：應(yīng)用服務(wù)器系統(tǒng)資源應(yīng)用服務(wù)器系統(tǒng)資源上圖中可以看到，對比之前的資源，swap基本上沒有了，CPU使用率多起來了。但是列依舊長，syCPU消耗還是有點多應(yīng)用服務(wù)器的si已經(jīng)到了13.1%了，這個值要關(guān)注下，暫時還不能說是問題，但是接著增網(wǎng)絡(luò)已經(jīng)超過70Mbps了，峰值上到87Mbps，這是一個好事，它說明現(xiàn)在處理的業(yè)務(wù)量接下來是數(shù)據(jù)庫服務(wù)器系統(tǒng)資源你可以看到數(shù)據(jù)庫CPU都用到這么高了TPS能到259.2了，較之前的221.5沒有提升多少。但是我們解決了swap的問題，還是那下一個瓶頸在哪里呢？通過上面的數(shù)據(jù)庫資源來看，數(shù)據(jù)庫早就已經(jīng)被用到了100%的CPU，隊列也嗖嗖地漲到了好幾十，高的 超過100了可見我們在處理應(yīng)用服務(wù)器的時候，數(shù)據(jù)庫這邊已經(jīng)早就吃不消了。那下面，我們就先后續(xù)性能工作建但是這里并不是說應(yīng)用服務(wù)器的優(yōu)化工作就完成了，還有一些部分需要優(yōu)化JVM置參數(shù)，至于應(yīng)該配置成什么值，還需要再測試，可能會有人說，這個測試人員怎么知道呢？請你相信，如果這個值性能測試人員都測試不出來的話，一般的架構(gòu)師通過分析確定swapiness的值網(wǎng)絡(luò)帶寬又快到占滿了，如果TPS再提高，網(wǎng)絡(luò)肯定又支撐這些扣也都放在這里。因為我們主要是找到系統(tǒng)的短板，并一一解決，才能使整體 增加，雖說現(xiàn)在應(yīng)用服務(wù)器上還有優(yōu)化的空間，但是現(xiàn)在它不是最短的板我們在不忘記應(yīng)用服務(wù)器這些問題的同時，再將目光轉(zhuǎn)向數(shù)據(jù)庫瓶頸分析定先來看看數(shù)據(jù)庫的系 資源我在很多場合都在強調(diào)一個詞：鏈。所以基本上分析也會是從OS層面開始像分析數(shù)據(jù)庫就更明顯。因為當我們不了解系統(tǒng)架構(gòu)時，想說明一個事情就非常。像上面的這個top，顯然usCPU用率非常地高，idle乎沒有了，只有一個si5.7si算高，我們在上一階段看到的應(yīng)用服務(wù)器的si已經(jīng)達到了13我們說si高或者低，倒不是關(guān)鍵，關(guān)鍵的是它有沒有成為我們的瓶頸點。在這個系統(tǒng)中，uscpu才是我們要關(guān)注的重點，因為它實在是太高了。對于一個數(shù)據(jù)庫來說，要干的事情就是執(zhí)行QL。當分析多了數(shù)據(jù)庫之后，基本上也形成了套路。不管怎么樣，還是先看一下基本的信息，以下截取一些tghtnL的有用的圖，如果你沒有這個工具，用其他的工具也是一樣的。從上面的圖可以看到，CPU使用率99%，QueryCache是OFF的。記下這個位置從上圖看到，負載隊列非常長，但DiskI/O沒多少，說明隊列和I/O無關(guān)，只是CPU的Network也不算大，進出每秒5000多個包，我們再來看一下網(wǎng)絡(luò)用到ps左右，即使是0s（注意！我這里說有余量是因為我同時也檢查了網(wǎng)絡(luò)隊列，并沒有阻塞，并不是只看了這個值就武斷地做了判通過上面的圖可以看到，每秒執(zhí)行2500-3000SQL，Sortspersecond800-1000，Sortrowspersecond達到8000-10000。session得倒是也不多，但MissRates壓力過程中QueryCache是在100%，并且從最上面的summary中可以看到QueryCache也是OFF的。為什么沒有在看到QueryCache是OFF的時候就敲黑板呢，這是因為在一些應(yīng)用中，如果不是查詢多的話，這個值OFF也不能說有問題，但是在這個應(yīng)用中幾乎所有的語句都是select，那這個QueryCache不打開就說不過去了呀。這里先記錄下這個問題，待會我們的優(yōu)化動作就是打開QueryCache。不管怎么說，對一個數(shù)據(jù)庫來說，主要是執(zhí)行SQL嘛，而對MySQL來說，不看slow通過整理slowlog，看到如下內(nèi)容##Overall:280total,1unique,0.59QPS,9.53xconcurrency #Timerange:2019-09-26T13:44:08to2019-09-##95%stddev==========================================5#6#7#00000008##RowsQuery10##RankQueryResponseCallsR/Call#================14555.086728016.2682SELECT什么情況？只有1unique？0.59TPS？我前面的TPS是有259.2，這結(jié)果一看就感覺代查看一下slow_launch_time，配置成了10s，怪不得看不SQL。改slow_launch_time為1s，再跑一遍?？吹饺缦陆Y(jié)果代1#Overall:620.47ktotal,30259.39QPS,16.76x2#Timerange:2019-09-26T13:44:082019-09-345Exec6Lock7Rows08Rows09Query12#QueryResponse#15116217418519嗯，這看著順眼多了。前SQL了所有執(zhí)行時間的96.8%！第一個SQL均執(zhí)行時間350ms，方差16%。而第二個語句更夸張，平均執(zhí)行時間16s，方差44%。這得收拾但是要不要優(yōu)化這樣的SQL，我們就需要根據(jù)SQL的分析和業(yè)務(wù)的分析來判斷了。這里我SQL1的執(zhí)行計沒有分不包含子查詢或者union操作全表掃第一個表所查有70行，第二個表所查有631行，此值僅做為參考，并不精準第一個表返回結(jié)果只占了行數(shù) 1.43%（優(yōu)化點），第二個表返回結(jié)果只占0.16%（優(yōu)化點）在第一個表中，Extra有一個值，usingwhere在第二個表中，Extra有一個值，Rangecheckedforeachrecord(indexmap:。SQL2的執(zhí)行計沒有分不包含子查詢或者union操作非唯一索引查找，也列出了具體的第一個表索引列上有102570行，第二個表索引列上有118行。此值僅做為參考，并不第一個表返回結(jié)果只占了行數(shù) 3.33%（優(yōu)化點），第二個表返回結(jié)果占100%在第一個表中，Extra有三個值，usingindexcondition;usingwhere;filesort在第二個表中，Extra有一個值，usingwhere這里我要敲黑板了?。?！你是不是不記得Extra些值的含義了？是不是要祭出你的搜我們這里再來回顧一遍usingwhere：對結(jié)果用where子句中的條件過濾Rangecheckedforeachrecord(indexmap:0x1)：MySQL沒有找到可以使用的索引，usingindexcondition：先條件過濾索引，找到所有符合索引條件的數(shù)據(jù)行，再用子句中的條件做過濾usingfilesort：Query中有Order By操作，又無法用索引完成排序，MySQL不得不選擇相應(yīng)的排序算法來實現(xiàn)。是不是對應(yīng)上了前面的sortspersecond？filtered比例能大一些，至于能不能用到索引，那就看業(yè)務(wù)的需要了，如果確實是要查很優(yōu)化結(jié)對數(shù)據(jù)庫，我們有兩個優(yōu)化的方向還記得吧，第一個是SQL語句，第二個是Query我們先做第2個，將QueryCache開啟，看一下效果如何代代1mysql>showvariableslike查看結(jié)果如下query_cache_typeON再執(zhí)行起來場景，看系統(tǒng)query_cache_typeON效果還不錯哦，usCPU降到了50%以下網(wǎng)絡(luò)峰值時能達到90Mbps了，又快把帶寬占完了。再檢查下隊列，這時看到已經(jīng)有接收隊列從TPS上來看，現(xiàn)在能到300多一點，同時網(wǎng)絡(luò)接收發(fā)送加在一起8M左右后續(xù)性能工作建接下來數(shù)據(jù)庫的優(yōu)化方向就是優(yōu)化SQL當然還有別的優(yōu)化建議，在后面再說這個案例從一個概括的描述開始，到各階段的分析定位，是一個非常完整的過程