記得在自己學(xué)習(xí)數(shù)據(jù)庫(kù)知識(shí)的時(shí)候特別喜歡看案例,因?yàn)閮?yōu)化的手段是容易掌握的,但是整體的優(yōu)化思想是很難學(xué)會(huì)的。這也是為什么自己特別喜歡看案例,今天也開始分享自己做的優(yōu)化案例。
今天整理了一下自己做過優(yōu)化或各種方案的客戶已經(jīng)超過100家了,今天分享的案例算是在這些客戶中比較典型的了!沒有什么高大上都是常見的問題!在之前的博客中都有過提及,那么本篇我們就結(jié)合之前的技術(shù)點(diǎn)來(lái)看看這個(gè)案例。學(xué)習(xí)優(yōu)化手段的看官們可以參見我的優(yōu)化系列:
系統(tǒng)環(huán)境
首先我們來(lái)看一下這個(gè)系統(tǒng)配置及現(xiàn)狀,為什么說(shuō)這個(gè)客戶經(jīng)典?那就是因?yàn)檫@個(gè)客戶已經(jīng)達(dá)到可以慢的地方都慢,不該慢的地方也慢!
首先這是一套醫(yī)院的HIS系統(tǒng),慢到什么程度呢?各種功能卡死不管是交款、醫(yī)囑、開藥一些列幾乎所有的功能都慢。但是卡慢的現(xiàn)象只出現(xiàn)在上午的高峰期!
先來(lái)看看系統(tǒng)配置 :
數(shù)據(jù)庫(kù)版本是SQL SERVER 2008R2,數(shù)據(jù)量大概1個(gè)多T,服務(wù)器64CPU 、128G內(nèi)存,服務(wù)器只運(yùn)行數(shù)據(jù)庫(kù)。
咋一看服務(wù)器確實(shí)有點(diǎn)老了,數(shù)據(jù)量也大了,內(nèi)存和CPU什么的明顯不夠用了!
數(shù)據(jù)庫(kù)指標(biāo)
那么我們?cè)倏匆幌聰?shù)據(jù)庫(kù)的一些表象:
看到這些基本的指標(biāo),除了慢你能看出什么?問題出在哪里?怎么樣快速解決?能有一個(gè)優(yōu)化的步驟呈現(xiàn)在眼前么?
優(yōu)化階段一(常規(guī)優(yōu)化)
很多時(shí)候系統(tǒng)慢要究其原因,難道上線時(shí)候就這么慢?那不可能,廠商根本無(wú)法交付的!那么問題來(lái)了,什么時(shí)候開始慢的?對(duì)系統(tǒng)做過哪些調(diào)整?
簡(jiǎn)單的調(diào)研開始…給我的只有不到半天的調(diào)研時(shí)間…得知的基本問題就是系統(tǒng)在最近一月增加了很多功能,有上線了很多其他系統(tǒng)接口!
那么直接就搞新功能、新程序接口語(yǔ)句? 我認(rèn)為并不是這樣,從一名數(shù)據(jù)庫(kù)從業(yè)人員來(lái)說(shuō),看到這樣的系統(tǒng)一定要先解決大面積等待問題!個(gè)人經(jīng)驗(yàn)來(lái)看很多系統(tǒng)大面積等待解決系統(tǒng)會(huì)有個(gè)很大的提升和改善!
配合一些常規(guī)的調(diào)優(yōu)手段階段一開始了,主要給系統(tǒng)大面積創(chuàng)建影響高開銷大的索引,調(diào)整系統(tǒng)參數(shù),優(yōu)化tempDB、開啟快照讀等….具體不細(xì)說(shuō)了,前面系列文章中都有!
預(yù)期:
一般系統(tǒng)上面一輪優(yōu)化會(huì)有明顯的改善,我認(rèn)為這一輪以后系統(tǒng)會(huì)明顯變快,語(yǔ)句CPU會(huì)下降到70%左右,內(nèi)存壓力也會(huì)有所減少。
結(jié)果:
自信滿滿的我第二天去了各個(gè)科室….部分功能依然超時(shí)還是各種慢…CPU依然90%以上,內(nèi)存壓力依然明顯。但是收集的數(shù)據(jù)來(lái)看,長(zhǎng)時(shí)間語(yǔ)句數(shù)量已經(jīng)大幅降低,系統(tǒng)等待阻塞情況也明顯好轉(zhuǎn)。
優(yōu)化階段二(針對(duì)語(yǔ)句)
再次分析解決大面積語(yǔ)句阻塞的系統(tǒng),發(fā)現(xiàn)現(xiàn)在的情況,主要有如下幾個(gè):
再次對(duì)系統(tǒng)調(diào)研:
-
系統(tǒng)中還有哪些消耗資源高的語(yǔ)句,是否能優(yōu)化。
調(diào)研后,我遇到了最常見也是最大的問題: 語(yǔ)句慢由于程序!很多人看到這會(huì)說(shuō)程序慢就改唄,那有啥問題? 問題就在于你來(lái)做優(yōu)化直接了當(dāng)?shù)暮腿思议_發(fā)人員說(shuō)你程序太爛必須改!如果你是程序開發(fā)人員你會(huì)有什么樣的反應(yīng)?
他會(huì)說(shuō):對(duì)不起,影響太大改不了!
那么這個(gè)優(yōu)化項(xiàng)目黃了,或者你要付出更大的代價(jià)繞過這樣的問題。
分析中發(fā)現(xiàn)程序使用了大量各種自定義函數(shù),有一定經(jīng)驗(yàn)的人都應(yīng)該知道,語(yǔ)句在篩選的列上使用函數(shù)是沒有辦法使用索引查找的,這樣相對(duì)于這種單表數(shù)據(jù)就幾百甚至幾千萬(wàn)的表,是何等的災(zāi)難!但是不能冒然突出修改程序,那還能怎么優(yōu)化呢?大概分析后得出結(jié)論,程序主要消耗在幾部分:
-
接口語(yǔ)句慢(主要是視圖,供其他程序調(diào)用)。
針對(duì)第一部分在不能改程序的情況下,嘗試添加計(jì)劃向?qū)Ц淖冋Z(yǔ)句執(zhí)行情況;
針對(duì)第二部分修改接口視圖,包括替換掉函數(shù)、添加索引等;
針對(duì)第三部分報(bào)表這東西不是短期就可以優(yōu)化的,所以再原有鏡像的方案上添加快照,實(shí)現(xiàn)了簡(jiǎn)單的讀寫分離,直接分走;
語(yǔ)句優(yōu)化的效果:
預(yù)期:
90%消耗高的語(yǔ)句都得到了優(yōu)化,系統(tǒng)應(yīng)該可以快起來(lái)了,CPU、內(nèi)存指標(biāo)也應(yīng)該正常了!
結(jié)果:
語(yǔ)句的消耗和時(shí)間都降下來(lái)了,系統(tǒng)卡慢現(xiàn)象有明顯好轉(zhuǎn),但是CPU依然90%以上、內(nèi)存壓力依然明顯,磁盤隊(duì)列還是很高!系統(tǒng)性能問題依然存在。
優(yōu)化階段三(深入指標(biāo)分析)
經(jīng)過前兩個(gè)階段的優(yōu)化一般系都會(huì)明顯好轉(zhuǎn),并且指標(biāo)正常,這也是前面提到的可以慢的地方慢已經(jīng)解決,那么為什么CPU、內(nèi)存壓力沒有緩解?難道真的是64CPU、128G內(nèi)存不能支持了?需要加內(nèi)存換CPU?難道要做負(fù)載均衡?各種拆分?
CPU分析
首先我對(duì)CPU壓力進(jìn)行了分析,綜合語(yǔ)句的CPU消耗和CPU的表象來(lái)看,很大一部分應(yīng)該不是語(yǔ)句執(zhí)行消耗的!那么服務(wù)器上確實(shí)也沒有跑其他程序,CPU資源哪里去了?
看看這個(gè)計(jì)數(shù)器:
SQL的編譯次數(shù)高峰時(shí)間段達(dá)到每秒2000多次!很多書上寫過,相信很多看官也知道,語(yǔ)句不參數(shù)化會(huì)給CPU造成壓力,這就是個(gè)鮮活的例子!那么解決辦法也是比較粗暴,程序無(wú)法修改那么就在數(shù)據(jù)庫(kù)上開啟強(qiáng)制參數(shù)化。
看下效果:
我想不用多說(shuō)什么了!
內(nèi)存分析
看到了CPU的現(xiàn)象那么內(nèi)存的問題也有眉目了,這么多編譯即席查詢,首先看一下內(nèi)存中緩存了那些數(shù)據(jù):
SQLOPTIMIZER Singlepage占到了80多個(gè)G,而在查詢數(shù)據(jù)頁(yè)的緩存只有20個(gè)G,而且仍然在被不斷壓縮,那么內(nèi)存沒壓力就怪了!這個(gè)SQLOPTIMIZER Singlepage嘗試了一下是無(wú)法通過DBCC FREExxxxx的操作釋放的,所以在半夜直接重啟了SQL 服務(wù)!將近2年沒有重啟的SQL服務(wù)就這么折在我的手里了!
重啟后頁(yè)生命周期:
內(nèi)存這個(gè)問題,不知道是不是微軟的一個(gè)小BUG,查詢計(jì)劃的緩存?zhèn)人理解不會(huì)一直壓榨數(shù)據(jù)緩存的,客戶的數(shù)據(jù)庫(kù)沒有補(bǔ)丁,但是查閱08的各個(gè)補(bǔ)丁也沒有找到相關(guān)問題的修復(fù)。
也請(qǐng)遇到過或了解的朋友給點(diǎn)提示!
預(yù)期:
語(yǔ)句已經(jīng)優(yōu)化,阻塞情況也被解決,CPU、內(nèi)存、磁盤壓力也沒有了,系統(tǒng)肯定快起來(lái)了!
結(jié)果:
系統(tǒng)快起來(lái)了!
總結(jié)
文章只是簡(jiǎn)單的描述了一下某醫(yī)院HIS系統(tǒng)的優(yōu)化過程,當(dāng)然一周的工作僅僅通過一篇文章寫出全過程細(xì)節(jié)必然不那么詳盡,還望看官們見諒!
整個(gè)的優(yōu)化過程是程序只修改了2條語(yǔ)句,其他都是通過數(shù)據(jù)庫(kù)優(yōu)化手段完成。而且沒有添加任何硬件資源!
優(yōu)化過程主要分為:
系統(tǒng)整體調(diào)研:和科室用戶溝通慢的情況,系統(tǒng)最近變更情況,并收集數(shù)據(jù)。
常規(guī)優(yōu)化:調(diào)整數(shù)據(jù)庫(kù)參數(shù)配置,添加索引,解決阻塞。
再次調(diào)研:系統(tǒng)慢功能,慢語(yǔ)句。
關(guān)鍵詞標(biāo)簽:
數(shù)據(jù)庫(kù)優(yōu)化案例——某市中心醫(yī)院HIS系統(tǒng),數(shù)據(jù)庫(kù) HIS系統(tǒng),ERP,ERP系統(tǒng),ERP軟件,ERP系統(tǒng)軟件,ERP管理系統(tǒng),ERP管理軟件,進(jìn)銷存軟件,財(cái)務(wù)軟件,倉(cāng)庫(kù)管理軟件,生產(chǎn)管理軟件,企業(yè)管理軟件,拓步,拓步ERP,拓步軟件,免費(fèi)ERP,免費(fèi)ERP軟件,免費(fèi)ERP系統(tǒng),ERP軟件免費(fèi)下載,ERP系統(tǒng)免費(fèi)下載,免費(fèi)ERP軟件下載,免費(fèi)進(jìn)銷存軟件,免費(fèi)進(jìn)銷存,免費(fèi)財(cái)務(wù)軟件,免費(fèi)倉(cāng)庫(kù)管理軟件,免費(fèi)下載,
本文轉(zhuǎn)自:e-works制造業(yè)信息化門戶網(wǎng)
本文來(lái)源于互聯(lián)網(wǎng),拓步ERP資訊網(wǎng)本著傳播知識(shí)、有益學(xué)習(xí)和研究的目的進(jìn)行的轉(zhuǎn)載,為網(wǎng)友免費(fèi)提供,并盡力標(biāo)明作者與出處,如有著作權(quán)人或出版方提出異議,本站將立即刪除。如果您對(duì)文章轉(zhuǎn)載有任何疑問請(qǐng)告之我們,以便我們及時(shí)糾正。聯(lián)系方式:QQ:10877846 Tel:0755-26405298。