引子
經過漫長的等待，兒子終於出生了。欣喜之餘，就是各種手足無措，顧此失彼了。因爲不懂，心裏總是慌慌的，有點小毛病，恨不得一步就到醫院。
婆媳育兒觀念的差異，讓心亂如麻的我，又成了風箱裏的老鼠，兩個不服軟的女人都在考驗我的智慧，雖是極力從中斡旋，還是免不了爆發了一場婆媳衝突。
還是智慧少了，估計四大名著還得再讀一遍（唬一下人應該還是可以的:-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終於降溫了。
好吧，完事兒了，好吧，還少一張優化後的使用率，安靜多了吧。
結語
以上就是這次優化的大概過程了（箇中心酸，着實也不少），網站是個小網站（，好吧，大網站也輪不到我哩），啥都在一個服務器上，也許這些個三腳貓的東西入不了很多人的法眼哩。不過，對我來說還是一次滿難得的經歷了。
我相信我就是我，一定能火。如果能對你有幫助，十分榮幸，方便的話點個讚唄，讓我也高興下；寫得不對，你能吐個槽，我也十分榮幸，如果能再指點一二，那就萬分感激了。
最後，媳婦希望把兒子的名字，寫在博客裏，將來他要是搜索自己的名字（別說你沒幹過這事兒哦），能看到這篇博客，那也是美事兒一件了。
好吧，當媽首先還是想到的自己的娃；其實媳婦從懷孕開始，爲了娃，管住了嘴，邁開了腿；爬樓梯，轉公園，只爲能順產，有利於娃（雖說最後也沒能順產，付出也是蠻多）；生了娃，事就更多了。這就是養兒方知父母恩了。好吧，打住了，再說下次去就是秀恩愛了。兒子名叫：戢雨澤，媳婦取的，希望將來程序比我寫得好。
成爲一名優秀的程序員！