CPU使用率終於正常了——記一次訂餐系統事故處理

引子

　　 通過漫長的等待，兒子終於出生了。欣喜之餘，就是各類手足無措，顧此失彼了。由於不懂，內心老是慌慌的，有點小毛病，巴不得一步就到醫院。

　　 婆媳育兒觀念的差別，讓心亂如麻的我，又成了風箱裏的老鼠，兩個不服軟的女人都在考驗個人智慧，雖是極力從中斡旋，仍是免不了爆發了一場婆媳衝突。

　　 仍是智慧少了，估計四大名著還得再讀一遍（唬一下人應該仍是能夠的:-D）。

　　 不過話說回來了，雖然苦點，累點（固然了，主要仍是媳婦和媽累，媳婦放棄工做，放棄辣椒，放棄方便麪，也蠻拼了，我也就打打醬油），但抱着娃，看他那惹人愛的臉，時不是還會 喔喔衝你迴應，偶爾還會咧嘴微笑...,啥苦，累，煩勞統統都沒有了。

　　 至今已兩月有餘，總算是平穩了，各個操做都熟練了，婆媳有了她們的相處模式，也虧得二位都是深明大義的人，雖也要不時開解，矛盾常有，衝突不在。也蠻好了。

　　 囉嗦了兩句，咱言歸正傳--記錄一次訂單系統CPU使用率太高處理。

 

　　 ——————————開場完畢，迴歸主題——————————

 

事故回放

　　當時的狀況是那個樣子的：

　　1，正值飯點，客戶電話說系統慢，幾乎沒法完成訂單調度，有時還顯示內存不足。當時內心的第一個聲音就是，服務器配置過低了，遠程一看，2核4G內存，cpu平均60%以上，內存70%以上，果真是配置低了，word哥厲害了，

不用看就知道了，果斷讓用戶增長了配置，嘿，你別說增長了配置果真，快了很多，立竿見影，錢還真是萬能。而後，欣欣然吃飯去了。

　　2，過了半月，又值飯點，客戶電話又說最近系統慢，再讓客戶增長配置吧，也不合適，爲了不打臉，我又盲目的臨時增長了服務器帶寬，可是然並卵。我已經知道我必需要爲本身當初的草率還債了。

      這些年，只知埋頭寫程序，這方面的東西幾乎沒有積累。然已經兵臨城下，會不會都得上，即便前路是如一重山，兩重山，山高天遠仍是山。 　　

　　　

確認帶寬

　　咱們打開一個網站慢，咱們首先想到的是服務器帶寬問題，可是如何確認服務器的帶寬是否足夠呢，我學到了兩個方法：看阿里雲網絡監控，看服務器聯網狀況。原本是兩個每天看到的東西，愣是今天才明白，都很差意思是說本身是計算機專業畢業的了。懂的就飄過，權當我作個筆記吧，有錯的歡迎斧正，不能誤了別人哩。

　　  1，如下是阿里雲網絡監控數據圖，服務器使用 5Mbps 帶寬，說明咱們的出網理論能夠達到 5*1024kbps，服務器出網峯值4700多，說明夠用。

　　

        2，也有說這個數據不是特別準確，咱們也能夠登陸服務器遠程查看聯網信息，下圖網絡使用大概等於 0.05%*1Gbps ≈ 500kbps;

 

　　　　

　　   

　　觀察了兩邊的數據，我肯定了帶寬基本夠用的，再不用本身去臨時升級帶寬了，知識比錢還萬能，解決問題還能省錢。~~^_^~~~

　　

搞定內存

　　內存從的來的4G，升級到8G，仍是會提示內存不足，你說一天就2000多個子訂單，再讓別人加配置，怎麼好意思呢。監控進程，發現w3wp.exe,sqlserver.exe 點的內存多，且在不斷增長，直到最後程序提示內存不足時，依然還在吃內存。

　　w3wp.exe 是iis的進程，一個站點會生成一個進程，也許是程序中有bug，致使內存不斷增長，可是要去發現他，真不是簡單的事兒。那這個進程還能沒法無天了麼，固然，不是！。應用程序池能夠設置內存限制，這就是他的天了。以下圖。

　　

 

　　sqlserver.exe 是數據庫有進程，這不是費話麼，看名稱就知道了。他也會一直吃內存，吃到沒有爲止（話說他本身不把本身吃了呢），程序當然有問題，不知道他本身有沒有bug呢，無論了，給他劃一片天，讓他插翅難飛。

固然了，這終非治標之事，權宜之計了。

　　

　　內存就暫時這樣處理了，近期不影響使用了，要治標仍是得好好查代碼哩。上面的都是簡單設置就Ok了，接下來纔是重頭戲。

降溫CPU

　　CPU常年在60%以上，常常還會飈到80%多，服務器本身都照顧不過來了，怎麼還有心情響應別人呢。因此嘛，就慢了。（這麼簡單的道理，怎麼如今纔想明白呢。）再細看，佔CPU的全是 sqlserver.exe，好吧，哪哪都少不了你的，十處打鼓，九回在。不過話又說回來， sqlserver.exe成了潑婦罵街，哪哪在，還不是大家這個幫程序員逼的麼。 好吧，大哥莫說二哥，臉上麻子同樣多，咱仍是來相互理解吧。先上一張優化前的CPU使用率狀況圖，完事兒再上一個優化後的圖，放一塊兒怕是有了對比，就有了傷害。看了下圖，真是慘不忍睹，平均估計得有60好幾吧。

　　

 　　sqlserver.exe 常常佔很高CPU，確定不是一處兩處的問題，因此確定不是如大海撈針通常在代碼裏找了，好吧，你們都知道是 數據庫引擎優化顧問，具體使用就不說了吧。直接優化建議，按裏建立索引之類的，這也太簡單了吧，確實簡單，由於也沒有太大的效果。

　　因而，繼續看查看報告一欄，畢竟這裏是真實的數據統計，每一個報告都略微看了下，當看到表報告時，word哥，當時真傻眼了，管理員表竟然成了引用數最多的表，這太不能接受了。真是不看不知道，一看笑一笑。笑啥呢，找到部分問題了還不讓笑了麼，哈哈哈。原來頁面中幾乎都會用到當前登陸用戶的信息，但每次又都是根據cookie中的id去查數據庫，我說呢，果斷緩存登陸的帳號信息（這多年了，仍是這麼陳舊的方式，還望有園友能夠指點一二）。

　　

 

　　通過上一步後，CPU由原來常年飈高，變成常常升高，檢查訪問頻率高的界面，結合優化報告，發現查詢條件  DATEDIFF(day,OrderDateTime,GETDATE()) =0 很是可疑，這個字段本已經添加了到了非彙集索引裏，但這樣寫後，執行計劃變得

很是複雜，若是我修改爲  OrderDateTime > '2016-10-26' 執行計劃就簡單多了。幾個高頻頁面計劃都是這樣寫的，之前以爲這樣寫很是牛，還爲常常記不住函數寫法而懊惱，沒文化真可怕。

　　再把優化報告，詳情看了後，完成了一系列優化，主要也是就索引，sql語句寫法等。索引吧，我是每天嚷嚷着學習，可是總是隻知皮毛，悲傷中。

　　把上面優化部署後，仍是會偶爾忽然升高CPU，猜多是某個不是特別高頻率的界面引發的，最後猜多是後臺首頁，有一些統計信息。果不其然，我每刷新一次，CPU就升高了，這些統計又不能沒有，怎麼辦呢，對了，仍是緩存，這些數據也沒有必要實時統計。以下圖。到這裏CPU終於降溫了。

　　

　　好吧，完事兒了，好吧，還少一張優化後的使用率，安靜多了吧。

　　

　　

結語

　　以上就是此次優化的大概過程了（箇中心酸，着實也很多），網站是個小網站（，好吧，大網站也輪不到我哩），啥都在一個服務器上，也許這些個三腳貓的東西入不了不少人的法眼哩。不過，對我來講仍是一次滿可貴的經歷了。

我相信我就是我，必定能火。若是能對你有幫助，十分榮幸，方便的話點個讚唄，讓我也高興下；寫得不對，你能吐個槽，我也十分榮幸，若是能再指點一二，那就萬分感激了。

　　最後，媳婦但願把兒子的名字，寫在博客裏，未來他要是搜索本身的名字（別說你沒幹過這事兒哦），能看到這篇博客，那也是美事兒一件了。

　　好吧，當媽首先仍是想到的本身的娃；其實媳婦從懷孕開始，爲了娃，管住了嘴，邁開了腿；爬樓梯，轉公園，只爲能順產，有利於娃（雖然說最後也沒能順產，付出也是蠻多）；生了娃，事就更多了。這就是養兒方知父母恩了。好吧，打住了，再說下次去就是秀恩愛了。兒子名叫：戢雨澤，媳婦取的，但願未來程序比我寫得好。

 

　　 成爲一名優秀的程序員！