JTSQLServer性能調(diào)優(yōu)札記之一

字號:

發(fā)現(xiàn)問題
    今天服務(wù)器檢查的時(shí)候發(fā)現(xiàn)SQL Server 2005服務(wù)器的CPU負(fù)載很高,而且一直居高不下:
    服務(wù)器是一臺4路服務(wù)器有4顆XEON 3GHz的CPU,8G的內(nèi)容,SQL Server 2005是32位,打了SP2。
    該服務(wù)器上跑了很多個(gè)業(yè)務(wù)系統(tǒng)的數(shù)據(jù)其中屬于JT的數(shù)據(jù)庫就有好幾個(gè),業(yè)務(wù)量還是挺大的。
    排除是其他進(jìn)程搞的鬼,確定是SQL Server 進(jìn)程把服務(wù)器搞得這么忙。
    定位問題
    打開活動(dòng)監(jiān)視器按照CPU排序,得到如下信息,可見jt_user在jt_ComitOA上面的連接所作所為都是大動(dòng)作啊。
    接下來換一個(gè)工具,SQL Server Profiler 出場,調(diào)整跟蹤的屬性,調(diào)整為只是監(jiān)視“SQL:Batch Completed”,而且將“DatabaseName”這個(gè)列選上,再調(diào)整一下列篩選器。
    這個(gè)列篩選器有個(gè)小Bug,輸入完條件后按一下回車,否則有可能輸入無效,OK開始我們的跟蹤之旅。我這里簡單地設(shè)置了一下DatabaseName,LoginName,CPU和Duration ,以便過濾掉一些無關(guān)緊要的值。
    經(jīng)過半個(gè)小時(shí)的收集,我得到了如下的跟蹤信息:
    我將部分語句Copy出來,順便整理了一下格式。
    exec oa_SWLIST
    ’glzyf’,
    ’(s.fileSerialNumber like ’’%%’’ or s.title like ’’%%’’ or s.keywords like ’’%%’’ or s.fileZi like ’’%%’’) and ’,
    ’ ( ft.userid=’’glzyf’’ ) ’
    exec oa_DBSX ’cwkfss’,’’
    exec oa_FlowTurning ’jgstyb’
    update FlowTurning set readStatus=1 where type=’sw’ and pkid=’21712’ and userid=’cwkfss’
    其中第一條語句的的占用率最嚴(yán)重,比其他的語句足足多了一個(gè)數(shù)量級。