引子
經過漫長的等待，兒子終於出生了。欣喜之餘，就是各種手足無措，顧此失彼了。因為不懂，心裡總是慌慌的，有點小毛病，恨不得一步就到醫院。
婆媳育兒觀念的差異，讓心亂如麻的我，又成了風箱裡的老鼠，兩個不服軟的女人都在考驗我的智慧型，雖是極力從中斡旋，還是免不了爆發了一場婆媳衝突。
還是智慧型少了，估計四大名著還得再讀一遍(唬一下人應該還是可以的:-d)。
不過話說回來了，雖然苦點，累點(當然了，主要還是媳婦和媽累，媳婦放棄工作，放棄辣椒，放棄速食麵，也蠻拼了，我也就打打醬油)，但抱著娃，看他那惹人愛的臉，時不是還會 喔喔衝你回應，偶爾還會咧嘴微笑...,啥苦，累，煩勞通通都沒有了。
至今已兩月有餘，總算是平穩了，各個操作都熟練了，婆媳有了她們的相處模式，也虧得二位都是深明大義的人，雖也要不時開解，矛盾常有，衝突不在。也蠻好了。
囉嗦了兩句，咱言歸正傳--記錄一次訂單系統cpu使用率過高處理。
——————————開場完畢，回歸主題——————————
事故回放
當時的情況是那個樣子的：
1，正值飯點，客戶**說系統慢，幾乎無法完成訂單排程，有時還顯示記憶體不足。當時心裡的第乙個聲音就是，伺服器配置太低了，遠端一看，2核4g記憶體，cpu平均60%以上，記憶體70%以上，果然是配置低了，word哥厲害了，
不用看就知道了，果斷讓使用者增加了配置，嘿，你別說增加了配置果然，快了不少，立竿見影，錢還真是萬能。然後，欣欣然吃飯去了。
2，過了半月，又值飯點，客戶**又說最近系統慢，再讓客戶增加配置吧，也不合適，為了避免打臉，我又盲目的臨時增加了伺服器頻寬，但是然並卵。我已經知道我必須要為自己當初的草率還債了。
這些年，只知埋頭寫程式，這方面的東西幾乎沒有積累。然已經兵臨城下，會不會都得上，即使前路是如一重山，兩重山，山高天遠還是山。
確認頻寬
我們開啟乙個**慢，我們首先想到的是伺服器頻寬問題，但是如何確認伺服器的頻寬是否足夠呢，我學到了兩個方法：看阿里雲網路監控，看伺服器聯網情況。本來是兩個天天看到的東西，愣是今天才明白，都不好意思是說自己是計算機專業畢業的了。懂的就飄過，權當我做個筆記吧，有錯的歡迎斧正，不能誤了別人哩。
1，以下是阿里雲網路監控資料圖，伺服器使用 5mbps 頻寬，說明我們的出網理論可以達到 5*1024bps，伺服器出網峰值4700多，說明夠用。
2，也有說這個資料不是特別準確，我們也可以登入伺服器遠端檢視聯網資訊，下圖網路使用大概等於 0.05%*1gbps ≈ 500bps;
觀察了兩邊的資料，我確定了頻寬基本夠用的，再不用自己去臨時公升級頻寬了，知識比錢還萬能，解決問題還能省錢。~~^_^~~~
搞定記憶體
記憶體從的來的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終於降溫了。
好吧，完事兒了，好吧，還少一張優化後的使用率，安靜多了吧。
結語以上就是這次優化的大概過程了(個中心酸，著實也不少)，**是個小**(，好吧，大**也輪不到我哩)，啥都在乙個伺服器上，也許這些個三腳貓的東西入不了很多人的法眼哩。不過，對我來說還是一次滿難得的經歷了。
我相信我就是我，一定能火。如果能對你有幫助，十分榮幸，方便的話點個贊唄，讓我也高興下;寫得不對，你能吐個槽，我也十分榮幸，如果能再指點一二，那就萬分感激了。
最後，媳婦希望把兒子的名字，寫在部落格裡，將來他要是搜尋自己的名字(別說你沒幹過這事兒哦)，能看到這篇部落格，那也是美事兒一件了。
好吧，當媽首先還是想到的自己的娃;其實媳婦從懷孕開始，為了娃，管住了嘴，邁開了腿;爬樓梯，轉公園，只為能順產，有利於娃(雖說最後也沒能順產，付出也是蠻多);生了娃，事就更多了。這就是養兒方知父母恩了。好吧，打住了，再說下次去就是秀恩愛了。兒子名叫：戢雨澤，媳婦取的，希望將來程式比我寫得好。
CPU使用率終於正常了 記一次訂餐系統事故處理
經過漫長的等待，兒子終於出生了。欣喜之餘，就是各種手足無措，顧此失彼了。因為不懂，心裡總是慌慌的，有點小毛病，恨不得一步就到醫院。婆媳育兒觀念的差異，讓心亂如麻的我，又成了風箱裡的老鼠，兩個不服軟的女人都在考驗我的智慧型，雖是極力從中斡旋，還是免不了爆發了一場婆媳衝突。還是智慧型少了，估計四大名著還...
控制CPU使用率
我使用的是ubuntu 14.04版本，用的是自帶的系統監視器來觀察cpu使用率的變化。1.首先來說說怎麼控制cpu使用率，當程式執行乙個死迴圈的時候，使用率就會變成100 而當程式進入idle的時候，使用率就會很低 在別的程式不啟動的情況下 那麼控制cpu使用率就是調整它idle和busy的時間比...
cpu使用率統計
cat proc stat得到 user nice system idle iowait irq softirq stealstolen guest 的9元組 再採兩個夠短的時間點，做差計算即可 cat proc pid stat讀取到 pid 6873 程序號utime 1587 該任務在使用者態...