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

2022-01-24 05:34:03 字數 3817 閱讀 3183

經過漫長的等待,兒子終於出生了。欣喜之餘,就是各種手足無措,顧此失彼了。因為不懂,心裡總是慌慌的,有點小毛病,恨不得一步就到醫院。

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

還是智慧型少了,估計四大名著還得再讀一遍(唬一下人應該還是可以的:-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常年在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 該任務在使用者態...