金蝶K3產(chǎn)品性能穩(wěn)定性優(yōu)化指導(dǎo)手冊

1、 金蝶K/3產(chǎn)品性能穩(wěn)定性優(yōu)化指導(dǎo)手冊(輔助工具)（V3.0）ã金蝶軟體(中國)有限公司研發(fā)中心K/3產(chǎn)品事業(yè)部.設(shè)計(jì)部解釋目的本手冊在於指導(dǎo)技術(shù)支援人員、分支機(jī)搆實(shí)施服務(wù)人員和客戶處理K/3系統(tǒng)應(yīng)用過程中產(chǎn)生的性能問題、中間層伺服器問題等；同時也指導(dǎo)我們的實(shí)施服務(wù)人員和客戶在實(shí)施中如何避免將來可能發(fā)生的性能問題和中間層問題。讓研發(fā)人員、技術(shù)支援人員和分支機(jī)搆實(shí)施人員一起共同提高工作能力，快速反應(yīng)快速解決客戶的問題。適合對象本手冊的主要閱讀物件是K/3系統(tǒng)研發(fā)人員、技術(shù)支援人員、實(shí)施人員、客戶服務(wù)人員和公司授權(quán)的有一定技術(shù)能力的客戶系統(tǒng)管理員?；仞伇臼謨允菍ρ邪l(fā)在處理客戶性能和穩(wěn)定性

2、問題的收集和總結(jié)，所以涉及到的面有可能還不夠。完善本手冊，提供一個更加完整的客戶問題解決指導(dǎo)方案，離不開大家的支持，所以大家在碰到相關(guān)的問題時，請回饋K/3設(shè)計(jì)部，我們將及時對手冊更新。導(dǎo)讀本手冊包括資料庫、中間層、用戶端和輔助分析工具介紹四大篇，分別介紹K/3客戶性能和穩(wěn)定性問題的處理方法、案例以及輔助工具，請您根據(jù)您的需要選擇相應(yīng)的章節(jié)閱讀。 注意由於此手冊可能牽涉一些K/3在技術(shù)方面的細(xì)節(jié)，為了防止有些人用意不良，斷章取義來攻擊K/3和公司，請注意保密。目錄目錄2輔助分析工具介紹31.1 WINDOWS任務(wù)管理器31.2 SQL Server的事件探查器（SQL-PROFILE）41.3

3、 資料庫阻塞監(jiān)測工具111.4 K/3性能監(jiān)控工具131.5 元件服務(wù)151.6 SQLDiag.exe171.7 性能監(jiān)視器(Performance Monitor)191.8 VBCheckW2k231.9 ADPlus231.10 COM+ SPY261.11 Process Explorer271.12 DebugDiag291.13 WinDBG321.14收集電腦資訊工具321.15檢查網(wǎng)路工具321.15.1 Ping321.15.2 Netstat341.15.3 ARP（位址轉(zhuǎn)換協(xié)定）341.15.4 Tracert351.15.5 IPConfig361.15.6 Rout

4、e361.15.7 nbtstat371.15.8 使用 pathping 測試路由器371.15.9 網(wǎng)路診斷實(shí)例：39附錄1：應(yīng)用/測試環(huán)境41附錄2：DTC一些資料41附錄3 中間層COM+問題分類和處理421問題分類421.1 COM+的掛起421.2 COM+ 出現(xiàn) 100% CPU431.3 COM+ 性能問題441.4 COM+ 異常441.5 COM+ 應(yīng)用記憶體洩漏442. COM+問題分類分析和處理方法462.1 COM+掛起462.2 CPU100%492.3性能問題492.4 COM+ 異常512.5記憶體洩露51輔助分析工具介紹如果系統(tǒng)出現(xiàn)問題，由於產(chǎn)生問題的原因很多

5、，可能是COM+元件出現(xiàn)了問題，或者是SQL Server資料庫的出現(xiàn)了問題，或者作業(yè)系統(tǒng)本身就存在問題，或者是網(wǎng)路存在問題。所以我們需要綜合多個可能的因素，使用一些輔助工具對系統(tǒng)進(jìn)行跟蹤檢測，然後分析跟蹤的結(jié)果，最終找到問題所在。下面就常見的一些輔助工具作一個簡單的介紹：1.1 WINDOWS任務(wù)管理器如果K/3系統(tǒng)很慢，是不是系統(tǒng)沒有可用的CPU和記憶體等資源了？Windows任務(wù)管理器可以幫助我們發(fā)現(xiàn)系統(tǒng)資源的使用情況。一)使用方法要打開“任務(wù)管理器”，請用右鍵單擊任務(wù)欄上的空白處，然後單擊“任務(wù)管理器”，或者把 “Ctrl+Alt+Delete”三個鍵同時按下，選擇“任務(wù)管理器”。 *

6、 選擇“性能”選項(xiàng)卡，如下圖：可以發(fā)現(xiàn)系統(tǒng)CPU和記憶體的使用情況。在系統(tǒng)出現(xiàn)性能問題時，監(jiān)測一段時間系統(tǒng)資源的使用情況。* 選擇“進(jìn)程”選項(xiàng)卡，如下圖：如果在上圖中發(fā)現(xiàn)CPU或者記憶體的使用率比較高，通過該圖，可以發(fā)現(xiàn)資源究竟被哪些進(jìn)程所消耗。是否還有別的系統(tǒng)（除K/3）消耗了寶貴的CPU和記憶體資源。下圖中可以看出SQL Server消耗了系統(tǒng)91的CPU，K/3消耗了8%的CPU。二)資料庫伺服器CPU曲線的一些典型結(jié)論由於資料庫是K/3系統(tǒng)的瓶頸，我們主要觀察資料庫伺服器的性能，通過觀察資料庫伺服器CPU的運(yùn)行曲線，可以得出一些典型結(jié)論。特別說明要觀察一段時間的CPU運(yùn)行狀態(tài)，而不是看

7、一瞬間的狀態(tài)。1）CPU持續(xù)100%一段時間如果發(fā)現(xiàn)資料庫CPU在某一段時間持續(xù)達(dá)到100%,成一條直線狀，這可以判斷是某項(xiàng)功能耗用了全部的CPU資源，這項(xiàng)功能如果是很少使用的計(jì)算功能或者是大資料量查詢，建議適當(dāng)安排,不要在業(yè)務(wù)高峰期運(yùn)行，如果是日常功能絕對需要優(yōu)化。如果能夠直接判斷是某項(xiàng)具體的功能最好，如果在併發(fā)下無法判斷到底是何功能。可以通過SQL-PROFILE跟蹤執(zhí)行時間較長的SQL。2）CPU大多數(shù)時間保持在40%以上如果資料庫伺服器CPU長期保持在40%以上，系統(tǒng)的運(yùn)行速度時快時慢，這表示CPU的負(fù)荷已經(jīng)很重。如果不能優(yōu)化軟體本身，升級硬體，增加CPU的個數(shù)可能是需要的。在這兒要說

8、明一點(diǎn)，不能認(rèn)為CPU達(dá)到100%才是CPU資源不足。3）良好的CPU狀態(tài)良好的CPU狀態(tài)是CPU能夠經(jīng)常跌落到40%以下，並且可以跌落到0。三)判斷資料庫記憶體是否夠用的一種簡單方法在任務(wù)管理器中選擇查看-顯示內(nèi)核時間，會顯示一條紅線，可以理解為磁片讀寫的時間，如果紅線很高證明大量的磁片讀寫操作，說明記憶體可能不夠，需要大量的記憶體切換。1.2 SQL Server的事件探查器（SQL-PROFILE）主要用來跟蹤資料庫的SQL執(zhí)行情況，發(fā)現(xiàn)耗時較長的SQL,從而發(fā)現(xiàn)影響性能的原因,分支機(jī)搆可以使用此工具得到跟蹤檔，把跟蹤檔返回到研發(fā)，用來分析和定位問題。這是最有效的定位分析問題的手段。一.

9、使用方法K/3出現(xiàn)性能問題，很多都是與SQL Sever資料相關(guān)。是否是一次查詢了太多的資料造成資料庫負(fù)載過大，出現(xiàn)性能問題？使用該工具可以使我們發(fā)現(xiàn)是哪些SQL 語句消耗了SQL Server資料庫的資源，對於發(fā)現(xiàn)性能問題會很有幫助，特別是給研發(fā)的軟體工程師們。SQL 事件探查器用於以下活動： 逐步分析有問題的查詢以找到問題的原因。查找並診斷運(yùn)行慢的查詢。捕獲導(dǎo)致某個問題的一系列 SQL 語句。然後用所保存的跟蹤在某臺測試伺服器上複製此問題，接著在該測試伺服器上診斷問題。監(jiān)視 SQL Server 的性能以精細(xì)地調(diào)整工作負(fù)荷。1）啟動事件探查器工具在“開始”功能表，依次指向“程式”、“Mic

10、rosoft SQL Server”，然後單擊“事件探查器”。 2）打開該程式後選擇“檔”功能表的“新建”的子功能表“跟蹤”，打開如下的介面：選擇SQL Server伺服器名稱（或者輸入IP位址，如果是本機(jī)器可以輸入“.”英文句號），然後輸入SQL Server的身份驗(yàn)證登陸名和密碼，可以和資料庫管理員聯(lián)繫。3）選擇“事件”選項(xiàng)卡n 在該圖中設(shè)置需要跟蹤的SQL Server事件類。主要用來跟蹤SQL語句和存儲過程的事件，通常情況下只要設(shè)置TSQL事件類的SQL:BatchCompleted，SQL:StmtCompleted事件和存儲過程事件類RPC:Completed、SP:Complet

11、ed，SP:stmtCompleted事件即可。4）選擇“資料列”選項(xiàng)卡，如下圖：在該圖中選擇要捕獲的數(shù)據(jù)列。建議把左邊的資料列全部添加到選定的資料列表中，捕獲完整，充分的資訊。設(shè)置完上面的資訊後，點(diǎn)擊“運(yùn)行”按鈕。對選定的資料庫伺服器進(jìn)行一定事件的跟蹤，然後另存為跟蹤文件，如下圖：可以對資料列：CPU（事件所使用的CPU事件，毫秒為單位），Reads（伺服器代表事件執(zhí)行的邏輯磁片讀取數(shù)），Writes（伺服器代表事件執(zhí)行的物理磁片寫入數(shù)），Duration（事件所花費(fèi)的事件總計(jì)，毫秒為單位）進(jìn)行查看，查找讀取或?qū)懭胛锢泶牌螖?shù)多的操作，耗時比較多的操作。為查找性能問題提供有力的證據(jù)，對性能優(yōu)

12、化也具有參考的價(jià)值。各個資料列的具體含義列舉如下表，以供參考查閱。數(shù)據(jù)列列號描述Application Name110創(chuàng)建與 SQL Server 實(shí)例的連接的用戶端應(yīng)用程式名。 該列由應(yīng)用程式傳遞的值填充，而不是由所顯示的程式名填充。 Binary Data2與在跟蹤中捕獲的事件類相關(guān)的二進(jìn)位值。 ClientProcessID19由主機(jī)電腦分配給進(jìn)程的 ID，在該進(jìn)程中客戶應(yīng)用程式正在運(yùn)行。如果用戶端提供用戶端進(jìn)程 ID，則填充此資料列。 Column Permissions44表明是否已設(shè)置了列許可權(quán)。分析語句文本，以確定將哪些許可權(quán)應(yīng)用到了哪些列。 CPU 18事件所使用的 CPU 時

13、間總計(jì)（以毫秒為單位）。 Database ID13USE database 語句所指定的資料庫 ID，如果沒有對給定實(shí)例發(fā)出過 USE database 語句，則是默認(rèn)資料庫。如果在跟蹤內(nèi)捕獲 Server Name資料列且伺服器可用，則 SQL 事件探查器將顯示資料庫名。 通過使用 DB_ID 函數(shù)確定資料庫的值。 DatabaseName35正在運(yùn)行用戶語句的資料庫的名稱。 DBUserName140用戶端的 SQL Server 用戶名。Duration 13事件所花費(fèi)的時間總計(jì)（以毫秒為單位）。 End Time 15事件結(jié)束時的時間。啟動事件的事件類（如 SQL:BatchStar

14、ting 或 SP:Starting）的該列不填充。 Error31給定事件的錯誤號。通常是存儲在 sysmessages 中的錯誤號。EventClass127捕獲的事件類類型。 EventSubClass121事件子類的類型，提供有關(guān)每個事件類的進(jìn)一步資訊。例如，Execution Warning 事件類的事件子類值代表執(zhí)行警告的類型： 1 = 查詢等待。查詢必須等待資源（如記憶體）才能執(zhí)行。2 = 查詢超時。查詢在等待執(zhí)行所需的資源時超時。所有事件類的該資料列均不填充。FileName36所修改的檔的邏輯名稱。 Handle33ODBC、OLE DB 或 DB-Library 所用的整數(shù)

15、，用以協(xié)調(diào)伺服器的執(zhí)行。 Host Name18正運(yùn)行用戶端的電腦名。如果用戶端提供主機(jī)名，則填充此資料列。若要確定主機(jī)名，請使用 HOST_NAME 函數(shù)。Index ID24受事件影響的物件上的索引 ID。若要確定物件的索引 ID，請使用 sysindexes 系統(tǒng)表的 indid 列。 Integer Data25與在跟蹤中捕獲的事件類相關(guān)的整型值。 LoginName11用戶的登錄名（SQL Server 安全登錄或 Microsoft Windows® 登錄憑據(jù)，格式為 DOMAINUsername）。LoginSid141登錄用戶的安全標(biāo)識號 (SID)。可以在 mast

16、er 資料庫的 sysxlogins 表中找到該資訊。對於伺服器中的每個登錄，SID 是唯一的。 Mode32不同事件所用的整數(shù)，用於描述事件已接收或要請求的狀態(tài)。 NestLevel29表示 NESTLEVEL 所返回的資料的整數(shù)。 NT Domain Name17用戶所屬的 Microsoft Windows NT® 4.0 或 Windows 2000 域。 NT User Name16Windows NT 4.0 或 Windows 2000 用戶名。Object ID22系統(tǒng)分配的物件 ID。ObjectName34引用的對象名。ObjectType28表示事件中涉及的物件

17、類型的值。該值對應(yīng)於 sysobjects 中的 type 列。Owner Name37物件所有者的資料庫用戶名稱。Permissions19表示所檢查的許可權(quán)類型的整型值。取值為： 1 = SELECT ALL2 = UPDATE ALL4 = REFERENCES ALL8 = INSERT16 = DELETE32 = EXECUTE（僅限於過程）4096 = SELECT ANY （至少一列）8192 = UPDATE ANY16384 = REFERENCES ANYReads16伺服器代表事件執(zhí)行的邏輯磁片讀取數(shù)。RoleName38要啟用的應(yīng)用程式角色名。Server Name1

18、26跟蹤的 SQL Server 實(shí)例名。Severity20異常錯誤的嚴(yán)重級別。 SPID112SQL Server 指派的與客戶端相關(guān)的伺服器進(jìn)程 ID。Start Time114啟動事件的時間（可用時）。State30等同於錯誤狀態(tài)代碼。Success23表示事件是否成功。取值包括： 1 = 成功。0 = 失敗例如，1 表示許可權(quán)檢查成功，0 表示該檢查失敗。TargetLoginName42對於以登錄為目標(biāo)的操作（例如，添加新登錄），是目標(biāo)登錄的名稱。TargetLoginSid43對於以目標(biāo)為登錄的操作（例如，添加新登錄），是目標(biāo)登錄的 SID。TargetUserName39對於以

19、資料庫用戶為目標(biāo)的操作（例如授予用戶許可權(quán)），是該用戶的名稱。TextData1與跟蹤內(nèi)捕獲的事件類相關(guān)的文本值。但是，如果正在跟蹤參數(shù)化查詢，則不以 TextData 列中的資料值顯示變數(shù)。Transaction ID4系統(tǒng)分配的事務(wù) ID。Writes17伺服器代表事件執(zhí)行的物理磁片寫入數(shù)。二.一些使用技巧n 在選擇要跟蹤的事件時不要使用默認(rèn)設(shè)置，一定要按照上面使用方法中的描述選擇部分事件，否則會跟蹤到很多無用的連接或回話資訊。選擇SQL:BatchCompleted，SQL:StmtCompleted事件和存儲過程事件類RPC:Completed、SP:Completed，SP:stmt

20、Completed即可。如果發(fā)現(xiàn)某一段時間有規(guī)律的發(fā)生性能問題，需要事先跟蹤，跟蹤一段時間，而不是問題已經(jīng)發(fā)生了再去跟蹤。跟蹤一段時間後，約1-2小時保存一次，否則跟蹤檔太大，耗用太多的記憶體會影響伺服器的記憶體。在保存時要選擇保存為跟蹤檔（默認(rèn)是這樣），保存為其他格式會丟失分析性能的資料，以前有分支機(jī)搆的人員就是保存為SQL腳本發(fā)給研發(fā)，這對分析問題毫無價(jià)值。跟蹤檔可能會很大，但是壓縮比例很高，壓縮後作為K/3性能問題診斷模版的一部分回饋給研發(fā)。為了不使跟蹤檔過大，在篩選條件上選擇Duration>=200的事件，因?yàn)閳?zhí)行週期很短的SQL不是我們在性能分析中關(guān)注的重點(diǎn)物件，同時全部SQ

21、L都跟蹤會很多，設(shè)置如下。附件是一個跟蹤檔的模版，SQL Server 本身也帶有很多的模版，在SQL Server安裝目錄80ToolsTemplatesSQL Profiler路徑下，如果有興趣也可以學(xué)習(xí)使用。如何跟蹤觸發(fā)器在跟蹤SQL的時候，可能會發(fā)現(xiàn)即使單條的Insert、Deleted、Update語句都會很慢。這種情況下，有可能是請求的資源被鎖定或者CPU等硬體資源不足等。除此之外，還可以檢查是否是觸發(fā)器造成的。有些觸發(fā)器工作不良好：如使用游標(biāo)來處理資料，或者由於觸發(fā)器的位置不對，使得本來可以批量處理的情況，只能單條處理。如：Master-Detail表資料結(jié)構(gòu)中，Detail表中

22、的觸發(fā)器只能處理一條Detail中的資料。而一般情況下，可以成批次處理Detail中的資料。通常開發(fā)人員也很少留意觸發(fā)器嵌套調(diào)用關(guān)係，因而對嵌套造成的後果，也很少考慮。種種原因，提醒我們值得去留意觸發(fā)器對SQL Server的影響。使用SQL Server Profiler是可以跟蹤到觸發(fā)器的執(zhí)行情況的，選擇事件中的存儲過程SP：StmtCompleted事件即可以跟蹤觸發(fā)器的運(yùn)行情況；選中NestLevel資料列則可以很好的瞭解到觸發(fā)器嵌套運(yùn)行情況。附件中是一個跟蹤觸發(fā)器的模版。三.主要跟蹤資料的解釋我們主要通過跟蹤資料中Duration(執(zhí)行週期)列的資料來發(fā)現(xiàn)那些耗用資料庫伺服器CPU特

23、別嚴(yán)重的SQL,然後去優(yōu)化他們的實(shí)現(xiàn)。如果你比較瞭解SQL,可以試著把SQL拷貝到查詢分析器，通過分析查詢計(jì)畫，建立合適的索引來優(yōu)化性能?；蛘呖梢园袲uration較長的SQL回饋到研發(fā)來分析。我們還需要關(guān)注Reads資料列，它代表磁片的邏輯讀次數(shù)，如果很多SQL語句的Reads次數(shù)都很高（達(dá)到幾十萬幾百萬甚至幾千萬次），這有可能是兩方面的原因。一方面有可能是記憶體不足，SQL Server頻繁切換記憶體資料。另一個可能的原因就是表和索引的存儲碎片太多，這可以通過在賬套管理中賬套優(yōu)化操作來解決，這個功能可以理解為磁片整理。關(guān)注CPU和Duration兩列的資料對比情況，可以判斷CPU資源是否足

24、夠，如果大多數(shù)SQL語句的CPU列資料明顯低於Duration，如果CPU曲線又很高，沒有發(fā)生嚴(yán)重的阻塞，我們可以認(rèn)為CPU的處理佇列太長，需要增加CPU資源。1.3 資料庫阻塞監(jiān)測工具有時候資料庫伺服器的CPU耗用很低，但是系統(tǒng)的整體性能很差，有可能是資料庫發(fā)生阻塞，在這兒有一個監(jiān)測工具可以得到阻塞情況。在查詢分析器上打開工具->選項(xiàng)，修改結(jié)果的設(shè)置選項(xiàng)把每列最多字元數(shù)修改為8000。把查詢結(jié)果改為文本顯示。在發(fā)生性能問題時在查詢分析中有問題的賬套上執(zhí)行如下SQL。把執(zhí)行結(jié)果保存為檔回饋到研發(fā)，研發(fā)人員會根據(jù)此結(jié)果得出一定的結(jié)論。1.4 K/3性能監(jiān)控工具工具路徑：Program Fi

25、lesKingdeeK/3ERPKDMainDbg.exe(或KDLogMonitor.exe)K/3性能檢測工具包括三個部分：1、用戶端診斷工具 2、用戶端代碼及跟蹤 3、COM+跟蹤工具.已在K/3V10.2中廣泛應(yīng)用並與K/3集成，幫助分析解決了一些性能問題，大大提高了開發(fā)效率。目前元件級跟蹤和COM+跟蹤，適用於K/3所有版本，甚至包括其他任何使用VB開發(fā)程式的產(chǎn)品，包括U8。1、用戶端診斷工具用於跟蹤後期綁定元件的介面物件創(chuàng)建、方法調(diào)用、運(yùn)行時間、執(zhí)行結(jié)果資訊等情況。以下是明細(xì)功能介紹:n 可以跟蹤物件創(chuàng)建的時間。VB本身對於物件創(chuàng)建出錯，一般用物件創(chuàng)建失敗或者Automation錯

26、誤提示。無法確定知道具體哪個元件出現(xiàn)問題，該工具可以明確標(biāo)識出創(chuàng)建失敗的組建名稱。K/3 V10.2安裝包調(diào)整過程中，遇到大量元件創(chuàng)建失敗情況，通過該工具迅速定位到創(chuàng)建失敗的元件，極大提高了解決安裝包問題的速度。n 提供了查找功能。方便了開發(fā)人員對於自己關(guān)心元件的查找，定位。n 增強(qiáng)了過濾功能，能將調(diào)用時間比較長的事件用藍(lán)色字體突出顯示，同時過濾掉調(diào)用時間很小的事件。n 將物件創(chuàng)建事件和方法調(diào)用事件分別用不同顏色顯示，便於識別；同時將沒有嵌套的方法調(diào)用使用一行來顯示2、用戶端代碼級監(jiān)測工具用於關(guān)鍵函數(shù)的運(yùn)行資訊的輸出，方便在客戶環(huán)境下定位程式問題、並提供性能資料收集。3、COM+跟蹤工具利用C

27、OM+本身的事件發(fā)佈模型，監(jiān)控COM+元件的方法調(diào)用，運(yùn)行結(jié)果資訊。主要用於COM+伺服器端的資訊跟蹤，查看哪個中間層元件調(diào)用時間長或記憶體消耗打，以確定性能問題或其他問題所在。（1）選擇要跟蹤的COM+應(yīng)用套裝程式（2）確定進(jìn)行跟蹤1.5 元件服務(wù)主要用來分析中間層的性能表現(xiàn)一)使用方法使用元件服務(wù)管理工具可以配置和管理 COM 元件及 COM+ 應(yīng)用程式，在K/3中間層伺服器監(jiān)視元件的使用情況。1）啟動元件服務(wù)管理工具在“開始”功能表，依次指向“程式”、“管理工具”，然後單擊“元件服務(wù)”。 2）檢查K/3中間層元件是否在運(yùn)行如下圖，選擇“Com+應(yīng)用程式”可以發(fā)現(xiàn)哪些元件正在運(yùn)行；選擇工具

28、條上的“狀態(tài)查詢”能夠更加直觀的查找哪些元件在運(yùn)行中。如果用戶端用戶比較多或者網(wǎng)路速度比較慢的情況下，中間層伺服器有可能出現(xiàn)服務(wù)，從而引起性能問題?？梢酝ㄟ^元件服務(wù)的事件列表檢查是否有比較多的事件在排隊(duì)等待。介面如下圖：二)如何找到正在執(zhí)行的資源耗用多的組件有時候如果中間層的CPU或記憶體耗用很嚴(yán)重，由於在多個客戶的併發(fā)下有時候客戶很難發(fā)現(xiàn)是那一項(xiàng)操作引發(fā)了問題，這時候可以找一下那一個元件包中的哪一個元件耗用資源比較嚴(yán)重，配合其他的觀察：如在此階段用戶都在做那些操作，有助於發(fā)現(xiàn)引發(fā)問題的功能。首先在任務(wù)管理器的進(jìn)程選頁簽上尋找耗用資源較多的DLLHOST進(jìn)程，在這兒說明一下，每一個中間層元件包

29、在運(yùn)行時有一個DLLHOST進(jìn)程，每一個包包含很多元件。找到耗用資源較多的DLLHOST，找對應(yīng)的PID(進(jìn)程標(biāo)示號)，根據(jù)PID在元件管理中可以找到對應(yīng)的元件包，然後在對元件包下面尋找調(diào)用時間長的元件，把此元件的資訊和其他用戶操作資訊回饋到研發(fā)，可以定位到具體的功能。三)如何判斷中間層的阻塞對於中間層伺服器，有可能發(fā)生阻塞，這時候主要看上面所描述的元件伺服器中事務(wù)列表中的元件排隊(duì)情況，如果有較長的排隊(duì)情況，就代表出現(xiàn)阻塞，可以考慮把組塞較多的元件分離出來重新放到一個新建的包中，因?yàn)槊恳粋€COM+元件包有一個進(jìn)程。四)關(guān)於STA模式COM+元件線程數(shù)限制問題對於VB編寫的COM+元件，由於不能

30、編譯為MTA線程模型，每個元件包進(jìn)程的線程數(shù)默認(rèn)為10個，也就是說同一個元件包中所有元件功能只能最多有十個同時運(yùn)行。對此問題，微軟提供了一個修改線程數(shù)量限制的方法，那就是修改註冊表選項(xiàng)，可以讓線程數(shù)達(dá)到100。此項(xiàng)改進(jìn)在V10.0已經(jīng)在安裝包做了修改，如果是以前版本的客戶可以直接修改中間層伺服器註冊表選項(xiàng)。可以直接把以下註冊表檔導(dǎo)入。 修改默認(rèn)設(shè)置後，會提高中間層的併發(fā)性能。1.6 SQLDiag.exeSQLDiag.exe 工具程式默認(rèn)的檔路徑位於 <系統(tǒng)磁碟機(jī)>: Program FilesMicrosoft SQL ServerMSSQLBinn 目錄之下，產(chǎn)生出來的日誌檔

31、默認(rèn)放在<系統(tǒng)磁碟機(jī)>:Program FilesMicrosoft SQL ServerMSSQLLOG 目錄之下，檔案名為 SQLDiag.txt。它可以在同一時間、一次幫你收集相當(dāng)多的資訊。在相同的時間區(qū)段內(nèi)，收集各種方面的資訊非常重要。例如你觀察到 SQL Server 對某個查詢的回應(yīng)遲緩，可能需要同時觀察系統(tǒng)硬體各項(xiàng)資源的使用，SQL Server 當(dāng)時的鎖狀況，是否有錯誤發(fā)生等等，必須要互相參照，才容易找出禍?zhǔn)住?SQLDiag.exe 就可以在同一時間搜集到相當(dāng)多的資訊，它必須在 SQL Server 伺服器本身執(zhí)行，而不能在用戶端工作站執(zhí)行。輸出的相關(guān)資料列述如下

32、：l 獲取記錄檔，若是 SQL Server 2000 的版本，這些記錄檔默認(rèn)是位於“<系統(tǒng)磁碟機(jī)>Program FilesMicrosoft SQL ServerMSSQLLOG”目錄下，名稱為 ERRORLOG 及副檔名是數(shù)字的先前版本，如 Errorlog.1、Errorlog.2 一直到 Errorlog.6 等等，若版本是 SQL Server 7.0，則這些記錄檔路徑默認(rèn)是 <系統(tǒng)磁碟機(jī)> MSSQL7log。 這些日誌檔是文本類型，雖然名稱是 ErrorLog，但放的不儘然是錯誤，SQL Server 會將一些資訊，如啟動時所完成的動作，放在這個檔中。當(dāng)

33、然，若有錯誤，也會存放在這個檔中，SQLDiag 默認(rèn)會將這些 ErrorLog 檔一併放到輸出結(jié)果的檔內(nèi)。 l 獲取相關(guān)的註冊(registry)資訊。 l 獲取相關(guān)程式庫(dll library)的版本資訊。 l 通過 sp_configure 系統(tǒng)存儲過程獲取 SQL Server 執(zhí)行實(shí)例的各項(xiàng)配置。 l 通過 sp_who 系統(tǒng)存儲過程獲取當(dāng)前登錄 SQL Server 執(zhí)行實(shí)例的用戶各項(xiàng)細(xì)節(jié)。 l 通過 sp_lock 系統(tǒng)存儲過程獲取鎖的相關(guān)資訊。 l 通過 sp_helpdb 系統(tǒng)存儲過程獲取 SQL Server 執(zhí)行實(shí)例內(nèi)各資料庫的相關(guān)資訊。 l 通過 xp_msver 擴(kuò)

34、展存儲過程獲取軟硬體平臺的簡要資訊。 l 通過 sp_helpextendedproc 系統(tǒng)存儲過程獲取擴(kuò)展存儲過程(extended stored procedures)的相關(guān)資訊。由於擴(kuò)展存儲過程是以 DLL 的形式與 SQL Server 的核心執(zhí)行在同一個程式中，若有任何閃失，輕則造成記憶體洩露，重則導(dǎo)致服務(wù)程式當(dāng)?shù)?。通過這個系統(tǒng)存儲過程會表列出所有的擴(kuò)展存儲過程，你可以將它的輸出與一般安裝的 SQL Server 做個比較，看看是否有用戶自行安裝的擴(kuò)展存儲過程，造成系統(tǒng)的不穩(wěn)定。 l 從 master.dbo.Sysprocesses 系統(tǒng)資料表獲取程式(process)的相關(guān)資訊。

35、當(dāng)系統(tǒng)忙碌時，你可以通過它觀察到底有哪些程式在伺服器內(nèi)執(zhí)行，各用了多少資源等等。搭配其他的系統(tǒng)存儲過程，如 sp_who、sp_who2、sp_lock 等等，可以獲得整體的狀況。例如通過 waittime 欄位知道有哪些程式已經(jīng)等待很久，從 cpu、physical_io 以及 memusage 欄位可以看出哪些程式在耗 CPU、磁片輸出入或記憶體資源。以及打開了事務(wù)，但執(zhí)行狀況卻是 sleeping 的不當(dāng)事務(wù)管理。 l 通過 DBCC INPUTBUFFER (spid) 獲取各進(jìn)程正在執(zhí)行的命令。 l 獲取鎖鏈接的起始者(head blocker)。 l 通過 MSInfo32.exe

36、 獲取系統(tǒng)的細(xì)節(jié)資料，這需要耗掉一些時間。 l 最後 100 個查詢和異常狀況 (Exception)。 SQLDiag.exe 獲取系統(tǒng)資訊是靠 MSInfo32.exe 工具程式取得系統(tǒng)的相關(guān)資訊，你可以直接執(zhí)行該工具程式以查看更豐富的資訊，如下圖： 點(diǎn)擊 MSInfo32.exe 主功能表的檔 - 導(dǎo)出選項(xiàng)，可以將系統(tǒng)當(dāng)前的各項(xiàng)資訊導(dǎo)出成文字檔案，供你日後參考。由於導(dǎo)出屬性包含軟硬體的各項(xiàng)細(xì)節(jié)資訊，所以按下導(dǎo)出後可能要稍等一下。SQLDiag.exe 是一個相當(dāng)容易執(zhí)行的工具程式，若要參照它的使用方式，可以進(jìn)入“命令提示符”程式，轉(zhuǎn)到 SQLDiag.exe 所在的目錄下執(zhí)行 SQLDi

37、ag /?(SQLDiag.exe 默認(rèn)目錄是 <系統(tǒng)磁碟機(jī)>:Program FilesMicrosoft SQL ServerMSSQLBinn)，以顯示各項(xiàng)參數(shù)，或是在 SQL Server 所附的“聯(lián)機(jī)文檔”利用 SQLDiag 關(guān)鍵字找尋使用的細(xì)節(jié)，URL 是：mk:MSITStore:C:Program%20FilesMicrosoft%20SQL%20Server80ToolsBooks coprompt.chm:/cp_sqldiag_96k9.htm以下簡述它各項(xiàng)參數(shù)的使用方式： -?：顯示使用說明。 -I <SQL Server 執(zhí)行實(shí)例名稱>：指定

38、要連接的本機(jī) SQL Server 執(zhí)行實(shí)例 (Instance)。若不指定 I 選項(xiàng)，則連接至本機(jī)默認(rèn)的執(zhí)行實(shí)例。 -U <帳號>：指定登錄 SQL Server 的帳號。 -P <密碼>：上述帳號對應(yīng)的密碼。若指定 -P 選項(xiàng)但不賦予值，則 SQLDiag 認(rèn)定密碼為空。密碼有區(qū)分大小寫。 -E：使用信任連接，也就是以當(dāng)前登錄作業(yè)系統(tǒng)的帳號來連接 SQL Server。 -O <導(dǎo)出檔案名稱>：將 SQLDiag 的導(dǎo)出重新導(dǎo)向到指定的檔。若未指定 -O 選項(xiàng)，則默認(rèn)輸出檔名稱為 SQLDiag.txt。此時，跟蹤檔案名稱仍維持原先的 blackbox.

39、trc 和 blackbox_01.trc。 若指定 -O 選項(xiàng)，則 SQLDiag根據(jù)你配置的名稱，重新命名跟蹤文件 blackbox.trc 和 blackbox_01.trc (例如，若output_file 指定為 MyDiagnostics.txt，跟蹤檔將分別重新命名為MyDiagnostics.trc 和 MyDiagnostics_01.trc)。 -X：排除錯誤日誌檔。 -M：執(zhí)行 DBCC 堆疊列印 (stackdump)。 -C：抽取聚集信息。 執(zhí)行範(fàn)例如下： SQLDiag -E -O diag.log 通過 E 參數(shù)，會以登錄作業(yè)系統(tǒng)的帳號登錄 SQL Server，

40、而 O diag.log 參數(shù)則會產(chǎn)生名稱為 diag.log 的輸出。1.7 性能監(jiān)視器(Performance Monitor)Windows NT 之後所附的性能監(jiān)視器是顯示各種性能資料非常詳盡的工具。你可以用它來觀測伺服器當(dāng)前的運(yùn)行，記錄整個系統(tǒng)多臺機(jī)器上的各種性能計(jì)數(shù)器，以找出整個系統(tǒng)的瓶頸。我們在性能調(diào)校的過程中會一再地用它。Windows NT 之後，就直接提供性能監(jiān)視器(Performance Monitor)，一般是用來查看、跟蹤在整個系統(tǒng)中，是否有哪個部分顯示資源不足的狀態(tài)，或是系統(tǒng)的使用狀況、演變的趨勢等等。而性能計(jì)數(shù)器代表的是一種指標(biāo)，它本身不是問題，某些背後隱含的問題

41、導(dǎo)致該指標(biāo)的變化。因此不要看到單一性能計(jì)數(shù)器的值就下定論，一定要建立推論：是什麼原因?qū)е略撔阅苡?jì)數(shù)器有當(dāng)前的值，若該原因是真的，那同時哪些性能計(jì)數(shù)器應(yīng)該顯示什麼現(xiàn)象？而你當(dāng)然應(yīng)該再進(jìn)一步分析與推論相關(guān)的計(jì)數(shù)器。性能監(jiān)視器讓你獲得證據(jù)以完成： l 支持自己的假設(shè)，或是推翻結(jié)論另尋原因。 l 獲取電腦全盤的狀態(tài)，讓你可以發(fā)現(xiàn)電腦發(fā)生了什麼狀況(WHAT) ，而不是為何(WHY)或如何(HOW)發(fā)生這種狀況。 l 抽取電腦變化的狀態(tài)，有基線以供比較是非常重要的，它讓你可以知道什麼是正常，而什麼不是。如果無法獲取基線，則尋找記錄中的變化，查看計(jì)數(shù)器相對的值而非絕對的值，並與先前的使用經(jīng)驗(yàn)做一個比較。除

42、了一般的硬體，如記憶體、硬碟、中央處理器乃至於網(wǎng)路等系統(tǒng)提供的性能計(jì)數(shù)器外，大部分微軟提供的伺服器軟體在安裝完畢後，也會註冊它自身的性能計(jì)數(shù)器，而 SQL Server 會增加相當(dāng)多類的性能計(jì)數(shù)器供你查核使用狀況，而這些性能物件皆以“SQLServer:”開頭。在要抽取性能的記錄之前，儘量將不相關(guān)的、當(dāng)前不需要的服務(wù)先停掉，如 IIS，系統(tǒng)掃毒等等。如果需要調(diào)校的電腦可能會當(dāng)機(jī)，則要採用遠(yuǎn)端記錄，避免資料未記錄到就掛了。相反地，若網(wǎng)路有問題，當(dāng)然需要在本機(jī)完成記錄。而一旦採用遠(yuǎn)端監(jiān)控，要先同步兩臺機(jī)器的時間才好比對結(jié)果。你可以在命令提示視窗中，通過以下的命令同步系統(tǒng)之間的時間：NET TIME

43、 RemoteMachine /SET就 SQL Server 的使用特性來說，依其重要程度，觀察硬體資源不足的順序依序是：記憶體、硬碟、中央處理器乃至於網(wǎng)路。SQL Server 是非常耗用記憶體的軟體，因?yàn)樗灿眠^的資料必先留在記憶體中，除非資源不足，否則不輕易從緩衝區(qū)清掉，讓資料庫的運(yùn)行儘量少使用硬碟。當(dāng)記憶體不足時，會連帶地影響硬碟和中央處理器。例如有新的資料要放到屬性已滿的緩衝區(qū)，則 SQL Server 內(nèi)部負(fù)責(zé)將緩衝區(qū)屬性更新到硬碟的 LazyWriter 程式就需要持續(xù)地執(zhí)行，好更新緩衝區(qū)的資料，並釋放較沒有使用到的記憶體區(qū)塊，這會同時讓 CPU 與硬碟忙碌起來。也就是說，當(dāng)

44、CPU 和硬碟性能不足時，有可能源頭是記憶體不足造成的。 磁片子系統(tǒng)的性能不佳，也一定會讓 SQL Server 性能好不起來，畢竟它需要大量讀寫存在硬碟上資料庫內(nèi)的資料。若你沒錢購置 RAID，最好也多買幾顆硬碟，讓 Log 檔、資料庫檔以及 Windows 作業(yè)系統(tǒng)用做虛擬記憶體的交換檔分在不同的硬碟上，因?yàn)檫@三種檔的設(shè)計(jì)目的不同，存取的習(xí)性與頻率也不同，當(dāng)三者在同一顆硬碟上時，有可能因?yàn)槎鄠€人存取資料庫，有的做更新，有的查詢，這些運(yùn)行讓作業(yè)系統(tǒng)要配置虛擬記憶體，因此硬碟要同時存取三種檔，這會導(dǎo)致磁頭忙碌地移動，讓硬碟的存取大多是隨機(jī)讀取，無法做循序讀取，導(dǎo)致硬碟性能降低。因此建議將三種檔

45、分別放在不同的硬碟上。 硬碟的性能遲緩，必定導(dǎo)致資料庫的查詢與資料異動延遲(這兩種動作分別是存取資料庫檔與 Log 檔)，這又造成事務(wù)要花較長的時間才能結(jié)束，進(jìn)而讓鎖的資源無法釋放，多人存取的系統(tǒng)彼此等待資源，進(jìn)入大家都被延遲的慘況。CPU性能的重要性不用強(qiáng)調(diào)了吧，它慢，週邊設(shè)備再快都沒有用。但要注意的是，我們當(dāng)前電腦的設(shè)計(jì)往往是中央處理器極快，但週邊運(yùn)行緩慢，導(dǎo)致CPU無法有效發(fā)揮它的能力。因此當(dāng)考慮加強(qiáng)中央處理器時，要看看是否是周邊設(shè)備的不足，導(dǎo)致CPU忙碌。一般來說，啟動性能監(jiān)視器後，只要記錄資訊而不需要做圖。以較穩(wěn)定的方式抽取電腦完整的狀態(tài)，由於在事前你很難預(yù)料判斷瓶頸時，會需要哪些資

46、料，所以儘量記錄所有的計(jì)數(shù)器5。如圖3.5 所示，除了通過默認(rèn)的視窗觀察系統(tǒng)當(dāng)前的情況外，最好還要通過添加記錄的方式，對系統(tǒng)作較長時間的監(jiān)控。執(zhí)行性能監(jiān)視器時間要長到足以抓取到問題，一般粗略的配置綱要如下：l 記錄2小時 每 4 秒記錄一次。 l 記錄1天 每 30 秒記錄一次。 l 記錄1天 每 180 秒記錄一次?；顒又械膱D形只能顯示瞬間的系統(tǒng)狀況，長時間記錄的資料才能看出趨勢 時間間隔不要小於 4 秒，以免記錄這個動作本身就傷害電腦的性能，除非是要抽取磁片 I/O 的性能，最高頻率也勿超過每 2 秒記錄一次。另外，為減輕對電腦長期的影響，若沒有特殊需求，只要記錄 2 小時就好。如果需要的

47、話，執(zhí)行'diskperf y ' 以抽取磁片的性能資訊。初次記錄時，在不傷及性能的前提下，僅可能地抽取所有的物件，供你對整個系統(tǒng)有一個全面性的概觀?？s略表列一般要記錄的物件如下(如果不可能取得全部物件)： l Cache, memory, objects, paging file, physical disk, logical disk, process, thread, processor, server, system。 l 所有的 SQL Server 物件。 l 如果有網(wǎng)路相關(guān)的問題，所有與網(wǎng)路相關(guān)的物件 (Protocol Stack Objects)。 一次記錄通

48、常無法包含所有需要的資訊，可能要多次後續(xù)不同的記錄資料。另外，在記錄上尚有其他的考量，如每個記錄存成一個檔，在記錄停止後，下次打開一個新的檔。檢查記錄檔所花的硬碟空間。若某個日誌檔屬性太大，而你只需要其中重要的部分，重新建立記錄(Re-logging)可能會很有用。日誌檔最大極限 1 gigabyte (GB)，而單一日誌檔太大也很難處理，可行的日誌檔大小應(yīng)該在 100 megabytes (MB) 左右，建議取 50 MB。若你需要長時間記錄，而系統(tǒng)是在 Windows NT 上，考慮以 script 自動停掉並重起記錄，以減低記錄檔大小。若在 Windows 2000 則可以利用 Sysm

49、on 的計(jì)畫任務(wù)，定時停掉並重起記錄，以分成多個日誌檔。 使用Windows XP 或 Windows 2003，可以通過 Relog.exe 工具程式對事件重新建立記錄，它可以將日誌檔轉(zhuǎn)換成不同的格式，並在新建立的日誌檔中包含較少的計(jì)數(shù)器數(shù)目。使用 relog.exe 的步驟如下： 1. 查看日誌檔資料：打開先前抽取的 .blg 文件。 2. 選擇你要繪圖的計(jì)數(shù)器。 3. 圖表上以滑鼠右鍵選擇“另存新檔”，格式為 HTML。 4. 將新建的 html 檔以附屬應(yīng)用程式的“記事本”打開。 5. 保留你有興趣的計(jì)數(shù)器，將其餘的計(jì)數(shù)器刪掉，同時把所有的格式通通刪掉，只保留如下的格式屬性： Comp

50、uterObjectParent/Instance#IndexCounter 若需要多個計(jì)數(shù)器，則每個名稱間以換行符號分開，範(fàn)例如下： BYRON2003NBMemoryPages/sec BYRON2003NBPhysicalDisk(_Total)Avg. Disk Queue Length BYRON2003NBProcessor(_Total)% Processor Time 其中 Computer 名稱可以省略。 6. 以一般文字檔案格式 ANSI 編碼存檔，或許換個檔案名比較合適，例如以 .txt 為副檔名。要小心的是默認(rèn)“Windows System Monitor”將 HTML

51、 格式的配置檔是以 Unicode 存檔，“記事本”會依照原編碼格式也就是 Unicode 存檔，而 Relog.exe 看不懂這種檔格式。 命令執(zhí)行範(fàn)例如下： relog SQLPerformance.blg -cf General.txt -f CSV -o General.csv 在範(fàn)例中，原始日誌性能的檔案名稱是 SQLPerformance.blg，而該檔以二進(jìn)位格式存放性能日誌資料，而我們只取部分的計(jì)數(shù)器，定義在 General.txt 文件中。過濾的結(jié)果將以逗號分隔的一般文字存檔，也就是默認(rèn)給 Excel 看的 .csv 檔，所以結(jié)果輸出到 General.csv 檔中，你可以直

52、接通過 Excel 打開查看分析。 上述步驟的相關(guān)細(xì)節(jié)可以參閱微軟支援網(wǎng)站，查詢檔“Q195654 Methods for Condensing a Performance Monitor Log File”，或是執(zhí)行範(fàn)例光碟第3章“重新過濾 Log”目錄下的myRelog.cmd 批次檔案來測試錄製完一段時間的系統(tǒng)執(zhí)行狀況後，接著要做的是顯示以及替日誌檔繪圖，Windows NT 所附的 Perfmon 受限在只能畫到 100%，而 Windows 2000 之後的 Sysmon 則可以超過這個範(fàn)圍。若系統(tǒng)間有不同時區(qū)的差異，Sysmon 會做調(diào)整，Perfmon 則不會。若要與其他的資料做

53、比較而時區(qū)不同，如 SQL Profiler 的跟蹤檔，可能會造成混淆。在查看資料時，應(yīng)先繪製全部記錄的圖表，以瞭解整體的趨勢。對於同一個日誌檔可以繪製多個圖表，以避免單一圖表顯示過多的資訊。為不同的記錄 instance 配置不同的值域範(fàn)圍(range)，若要突顯圖表中某個 instance 的線條，可以在下方區(qū)塊選到該線條後按快捷鍵 Ctrl+H。查看圖形時，利用時間範(fàn)圍 slider 來取得特定趨勢時段的細(xì)節(jié)，並利用鍵盤上的左右箭頭一次移動一個點(diǎn)，若偶有一兩個點(diǎn)遠(yuǎn)高出邊界，可能是除零運(yùn)算的結(jié)果，可以忽略不計(jì)。最後要注意的是不要利用 Windows NT 的 Perfmon 讀取 Wind

54、ows 2000 Sysmon 產(chǎn)生的日誌檔當(dāng)要分析記錄所得的資料時，尋找某些模式，以及不正常之高或低的計(jì)數(shù)值，這有助於瞭解什麼是“正?！敝担瑢⒒€是有幫助的，如果一個計(jì)數(shù)器顯示某個問題，可尋找其他的證據(jù)以支持你的理論，例如：l % Process Time 的值持續(xù)很高，瓶頸不一定是在 CPU 。也可能因?qū)嶓w記憶體不足，為了處理 page faults 造成很高的 %Privilege Time。 l SQL Server Total Server Memory 持續(xù)飆高不一定是 memory leak。Buffer Pool 會在 SQL Server 尚未用到記憶體限制或極限時，持續(xù)

55、增加。不要忘了查看 SQL Profiler 跟蹤檔、errorlog，或其他相關(guān)資訊，有助於解釋你在性能記錄所看到的現(xiàn)象。當(dāng)特定的計(jì)數(shù)值走高時：l SQL Profiler 是否同時抽取到值得注意的現(xiàn)象？是否有大量的 recompile 和 compile 事件？ l 是否有特別的查詢或批次處理工作在執(zhí)行？ l 是否在 errorlog 中看到任何錯誤或資訊？性能監(jiān)視器就介紹到此，我們接著要討論的是針對個別問題需要進(jìn)一步研究時，可以採用的工具程式。1.8 VBCheckW2k用於檢查使用VB編寫的DLL編譯是否正確，可以檢查整個系統(tǒng)中的COM+元件物件、IIS Web 應(yīng)用程式以及單個的DL

56、L檔l 使用方法：vbchkw2k /sc or dllname 參數(shù)說明：1：/sc 掃描IIS（進(jìn)程中），OOP Pooled、以及安裝在COM+元件和COM+目錄下的獨(dú)立的應(yīng)用程式；（由於K/3系統(tǒng)相應(yīng)的DLL比較多，可以把內(nèi)容輸出成一個日誌檔，然後在進(jìn)行分析，方式在後面加上” >log.txt “）2：dllname 掃描指定的DLL3：無 掃描IIS（進(jìn)程中），OOP Pooled、以及安裝在COM+元件下的獨(dú)立的應(yīng)用程式；l 示例命令：vbchkw2k /sc >log.txt結(jié)果：Scanning dllhost.exe (PID:828) kdsvrmgrC:WINNTsystem32KDCOMKdsv