查詢系統(tǒng)緩慢根源

筆者在一家制藥集團(tuán)企業(yè)，負(fù)責(zé)信息化管理，主要內(nèi)容涵蓋公司的ERP、HR等各類業(yè)務(wù)系統(tǒng)的運(yùn)維管理，公司的日常運(yùn)營依賴這些業(yè)務(wù)系統(tǒng)。

問題發(fā)生

近期，公司的HR業(yè)務(wù)系統(tǒng)訪問緩慢，該系統(tǒng)采用B/S架構(gòu)，前端為Windows 2008，后臺(tái)采用SQL 2008數(shù)據(jù)庫，因?yàn)槭切枰獮g覽器訪問的系統(tǒng)，開始筆者認(rèn)為是訪問者的網(wǎng)絡(luò)或電腦等個(gè)別問題，但隨著用戶的大面積反饋，筆者意識(shí)到事情并不簡單，應(yīng)該是系統(tǒng)出問題了。

集團(tuán)公司的薪酬發(fā)放與通知都依賴該業(yè)務(wù)系統(tǒng)，現(xiàn)在已是臨近工資發(fā)放期了，若因系統(tǒng)問題而耽誤集團(tuán)及各公司的薪酬結(jié)算工作，那影響可就大了。筆者不敢怠慢，急忙來到系統(tǒng)服務(wù)器所在機(jī)房進(jìn)行檢測排查，該系統(tǒng)是架設(shè)在兩臺(tái)IBM 3650 M4服務(wù)器上的，前期因服務(wù)器硬盤損壞導(dǎo)致系統(tǒng)停擺過，后經(jīng)筆者與服務(wù)器工程師的修復(fù)維護(hù)后，系統(tǒng)恢復(fù)了正常。這次再度出現(xiàn)系統(tǒng)問題，筆者懷疑還是系統(tǒng)硬件故障解決不徹底，于是將系統(tǒng)數(shù)據(jù)庫遷至一臺(tái)新服務(wù)器上，結(jié)果故障依舊。

問題與之前還是有所不同的，看來還要先從軟件入手。通過觀察，由于操作系統(tǒng)等外圍軟件環(huán)境正常，因此主要還是需要檢查業(yè)務(wù)系統(tǒng)，而系統(tǒng)前端占用資源很少，解決的重點(diǎn)還是在后臺(tái)數(shù)據(jù)庫端，該系統(tǒng)采用的數(shù)據(jù)庫為SQL Server 2008 R2。

處理過程

是不是數(shù)據(jù)庫負(fù)擔(dān)太重而導(dǎo)致運(yùn)行緩慢呢？為此，筆者首先關(guān)閉了SQL報(bào)表等閑置組件，目的是去除數(shù)據(jù)庫冗余組件，以便于系統(tǒng)輕裝前進(jìn)，減輕SQL數(shù)據(jù)庫的運(yùn)行負(fù)擔(dān)，但經(jīng)業(yè)務(wù)人員試用還是反映系統(tǒng)緩慢。筆者再度深入優(yōu)化，對(duì)SQL數(shù)據(jù)進(jìn)行了針對(duì)性的調(diào)優(yōu)處理，主要處理步驟如下。

1.在SQL Server管理器中選定數(shù)據(jù)庫，右擊鼠標(biāo)選擇屬性，看一下“常規(guī)”頁簽中數(shù)據(jù)庫目前使用大小及剩余空間大小，目的是看看SQL的運(yùn)行空間是否滿足基本需要。通過檢查發(fā)現(xiàn)一切正常。

2.重新設(shè)置AWE的內(nèi)存分配，目的是在32位版本的Windows操作系統(tǒng)上允許使用超過4GB的物理內(nèi)存，使32位版本的系統(tǒng)最多可支持64GB的物理內(nèi)存，具體操作是：

點(diǎn)擊SQL Server管理器中的左樹型框中第一列看屬性，打開AWE分配，設(shè)置分配給SQL Server最小、最大的內(nèi)存大小?，F(xiàn)場主機(jī)內(nèi)存如為32GB，則建議將最大、最小內(nèi)存的值調(diào)整為20GB，相關(guān)值設(shè)置的標(biāo)準(zhǔn)為數(shù)據(jù)庫主機(jī)內(nèi)存的60%（如圖1）。

在SQL Server管理器設(shè)置好AWE分配后，還要在本地安全策略中打開鎖定頁使其生效：

在Windows系統(tǒng)的運(yùn)行中輸入gpedit.msc，進(jìn)入計(jì)算機(jī)配置→Windows設(shè)置→安全設(shè)置→本地策略→用戶權(quán)限分配→內(nèi)存中鎖定頁面，將裝SQL Server數(shù)據(jù)庫的用戶加入到內(nèi)存鎖定頁面中。

3.查看SQL是否有出現(xiàn)阻塞鎖，對(duì)檢查出來的結(jié)果進(jìn)行截圖，并將阻塞會(huì)話的根源給kill掉，查看方法如圖2所示。

通過上述處理，情況依然沒有起色。筆者又采用重建索引維護(hù)計(jì)劃，收集業(yè)務(wù)系統(tǒng)客戶端與服務(wù)端線程信息，以定位是否程序有問題，及再度對(duì)Windows 2008 Server操作系統(tǒng)的外圍檢查，但通過一系列檢測依然沒有發(fā)現(xiàn)問題。

圖1 調(diào)整服務(wù)器內(nèi)存

圖2 查看SQL是否有阻塞鎖

因?yàn)樯鲜鲛k法是SQL Server處理較為常用及有效的手段，除此之處，就是需要深度優(yōu)化了，但這個(gè)過于專業(yè)，不是筆者所能處理的了。當(dāng)時(shí)供應(yīng)商工程師也建議過，實(shí)在不行可以切換到Oracle數(shù)據(jù)庫，據(jù)其介紹，Oracle較SQL的運(yùn)行效率及穩(wěn)定性方面更高一些，在應(yīng)對(duì)多用戶、大并發(fā)方面的效果更加明顯。但考慮公司數(shù)據(jù)庫體量還不是太大，另外，變更數(shù)據(jù)庫總是有風(fēng)險(xiǎn)的，畢竟一種類型數(shù)據(jù)強(qiáng)行并入另一品牌數(shù)據(jù)庫，還需要做多方面的轉(zhuǎn)換，未知因素與風(fēng)險(xiǎn)不好把控，慎重起見，沒有同意該方案，而是認(rèn)為還是要從當(dāng)前情況找原因。

解決方法

在長時(shí)間的查找與思考過程中，突然注意到服務(wù)器的硬盤燈一直在閃爍，這說明有大量讀寫數(shù)據(jù)的情況存在。會(huì)不會(huì)是I/O問題呢？因?yàn)榇罅康腎/O讀寫若無法及時(shí)響應(yīng)，也會(huì)成為瓶頸所在。該服務(wù)器是2014年購買的，當(dāng)時(shí)是按標(biāo)配（16GB內(nèi)存、300GB機(jī)械硬盤，而供應(yīng)商給的推薦配置為64GB內(nèi)存，最好是固態(tài)硬盤，當(dāng)時(shí)考慮到數(shù)據(jù)量較小且預(yù)算資金有限，就采用了標(biāo)配服務(wù)器來采購應(yīng)用。想到這里筆者有了思路，臨時(shí)找了一臺(tái)高性能服務(wù)器遷移過去，果然訪問效率有了大幅提升，看來就是這個(gè)原因。筆者在升級(jí)了服務(wù)器的硬件設(shè)備后，順利解決了問題。

經(jīng)驗(yàn)總結(jié)

事后通過反思，筆者總結(jié)以下幾點(diǎn)。

1.硬件平臺(tái)一定要及時(shí)升級(jí)更新。該標(biāo)配服務(wù)器盡管一開始能夠滿足需求，但隨著數(shù)據(jù)量與訪問量的增加，漸漸就不堪重負(fù)了，當(dāng)時(shí)筆者只一味地在軟件優(yōu)化上硬啃骨頭，沒有意識(shí)到硬件平臺(tái)升級(jí)的重要性，導(dǎo)致事倍功半。盡管開始也更換了服務(wù)器，但當(dāng)時(shí)誤以為是原故障解決不徹底，且更換的新服務(wù)器也是類似配置的服務(wù)器，因此沒能及時(shí)發(fā)現(xiàn)問題。由此看來，硬件平臺(tái)也是系統(tǒng)運(yùn)維管理中相當(dāng)重要的一部分，一定不要忽視。

圖3 操作系統(tǒng)與數(shù)據(jù)庫均為64位系統(tǒng)

2.AWE內(nèi)存優(yōu)化的處理事 倍 功 半。AWE（Address Windowsing Extensions）內(nèi)存，主要功能是允許32位應(yīng)用程序分配64GB物理內(nèi)存，并把視圖或窗口映射出2GB虛擬地址空間的限制。筆者所設(shè)置AWE的內(nèi)存分配，主要針對(duì)32位操作系統(tǒng)有效，而公司的服務(wù)器操作系統(tǒng)及數(shù)據(jù)庫系統(tǒng)均為64位（如圖3），所以這一舉措收效甚微。筆者開始以為這里是重點(diǎn)所在，結(jié)果耗費(fèi)了大量時(shí)間，明顯是走了彎路。

3.處理過程中一定要細(xì)心沉穩(wěn)，找出根源看似偶然，但中間即有實(shí)力也有運(yùn)氣的成分，更是建立在辛苦努力與大量的調(diào)研咨詢的基礎(chǔ)上，只有基礎(chǔ)工作扎實(shí)、到位了，才會(huì)有靈光一閃的點(diǎn)晴之筆。