2011年2月--2011年7月数据库性能优化过程
??? 2011年2月下旬的一天早上,昨天更新的系統,早上發現數據庫的服務器CPU達到100%,而且持續的時間很長,不得回到昨天更新前的版本,但系統還是有較長時間達到100%的情況,問題沒有解決,從這正式開始優化線上數據庫性能。
?
第一階段優化
?? 分析問題:
??? 一開始老是想找出問題的原因,找了3天還沒有頭緒,列出以下原因:
?? 1,JOB的耗時存儲過程? --太頻繁,執行時間長,1,2分鐘
?? 2,頻繁執行同樣的SQL? --如查詢用戶表sys_user 幾分鐘內執行數千次
?? 3,tempdb太小
?? 4,運行SQL太慢
?? 5,數據庫阻塞
???? 但這些原因,都找不出具體的在那塊有問題,好像都有,又好像都沒有,時間在一天天過去,但是系統還是100%經常發生,嚴重影響業務使用,這時只能按照以前的優化經驗調整優化思路,不找原因,只要是問題就優化,一個一個處理,最終解決系統性能問題:
?主要是執行優化方法:
? 1,刪除全部的主鍵聚集索引,改成唯一非聚集索引
? 2,刪除重建全部索引
? 3,刪除全部外鍵約束
? 4,持續優化SQL
? 5,使用行版本隔離級別
? 6,根據SQL建立索引
? 7,安裝SQL 2008 SP2補丁
? 8,禁止讀取大量數據未分頁的SQL,讀出數據必須分頁50條。
?
第二階段優化
? 經過一個多月的優化,比以前穩定一些,但系統100%的情況還有發生,這時分析下來,可能存在一些原因:
?? 1,高并發
?? 2,嚴重系統缺陷
?? 3,死鎖
?? 4,緩存問題
?? 5,循環調用SQL
?? 6,長事務
?? 7,未優化的SQL
? 為跟蹤以上出現的SQL,發現以前用的DMVS性能分析視圖遠遠不夠,必須使用SQL Profile等其他工具,這期間的確進步很大
?? 1,使用SQL Profile監控工具監控高耗CPU的SQL
?? 2,發現長事務,并優化程序和SQL缺陷
?? 3,發現SQL事務中的執行語句停頓問題
?? 4,跟蹤引起死鎖SQL,并分析死鎖原因和優化
?? 5,使用windows的性能工具分析CPU,Reads發現系統問題
?? 6,使用SSRS和windows的性能工具每天發送CPU跟蹤報表。
???
?第三階段優化
??? 經過一,二階段優化,系統100%比以前的少了很多,但有一天,看SSRS的CPU報表,突然CPU暴漲到100%,而且第二天還有,通過Profile發現是因為緩存更新的原因,由于后臺修改數據會觸發緩存更新,一旦后臺大量更新數據時,前臺就會更新大量緩存,這樣一來就要很多個SQL請求,CPU就會暴漲到100%,后來修改了程序緩存策略,該問題解決。
? ? 經過這三輪的優化,系統的性能比以前有了明顯的改善,系統100%的情況極少。經過這幾個月優化,徹底發現以前的知識和經驗不足,并一度懷疑自己的能力,為何以前優化系統,1,2個月就大概全部搞定,這次花了這么長時間,可能情況不一樣,系統的復雜程度也不一樣吧!
? 2011年3月3日CPU的趨勢圖
?
? 2011年5月3日CPU的趨勢圖
???? 2011年7月7日CPU的趨勢圖
???
轉載于:https://www.cnblogs.com/zping/archive/2012/01/12/2320806.html
總結
以上是生活随笔為你收集整理的2011年2月--2011年7月数据库性能优化过程的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: myeclipse 运行速度慢的解决方案
- 下一篇: MYSQL 去除重复 记录