【正文】 b*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINNT\system32\ 0006fd60 77a8a701 0000004c ffffffff 00079614 KERNEL32!WaitForSingleObject+0xf00000000 00000000 00000000 00000000 00000000 ole32!CoRegisterSurrogateEx+0x95b COM+ SPYCOM spy用於獲取COM+元件調(diào)用時相應的進程事件或者應用程式調(diào)用所花費的時間，來查找產(chǎn)生性能問題的瓶頸。何時使用，何時不使用在系統(tǒng)出現(xiàn)下面的情況時，可以考慮使用ADPlus：l 進程掛起l 在單個處理器電腦上100%的CPU，在雙CPU上50%CPU，在4個CPU上25% 的CPU等待l 進程出現(xiàn)異常或者非正常的關閉但在下面的情況不要使用ADPlusl 如果需要對程式進行故障檢查或者進程啟動時異常結束l 如在crash模式下使用對執(zhí)行性能有明顯的影響應用場景ADPlus應用的場景主要包括以下方面：l 進程掛起或者消耗100%的CPUl 進程異常結束l MTS或COM+服務應用異常結束l 在遠端Crash模式下運行l(wèi) 在Crash模式下監(jiān)視ADPlus使用方法l –hang –pn 獲取掛起進程的dump檔；l –hang –p 1860 獲取掛起進程ID為1860的dump文件；進程ID可以通過任務管理器來獲??；l crash –p 1860 獲取掛起進程ID為1860的crash文件；進程ID可以通過任務管理器來獲??；示例：1． 在CMD模式下， –hang –p 1960，出現(xiàn)下面的提示下面的資訊：2． 選擇確定後，系統(tǒng)將提示下面的資訊： 選擇確定選擇確定系統(tǒng)提示生成檔在：D:\Program Files\Debugging Tools for Windows\ Hang_Mode__Date_07202005__Time_16081515目錄下，該檔即是需要的DUMP檔。使用之前需要設置符號表資訊路徑：1：如果本地沒有符號表，但可以訪問網(wǎng)路可以在環(huán)境變數(shù)中增加下面的內(nèi)容set _NT_SYSMBOL_PATH=srv*DownstreamStore*；（DownstreamStore為本地符號表的目錄）。ADPlus 可以創(chuàng)建不同場景下的詳細的dump檔。 VBCheckW2k用於檢查使用VB編寫的DLL編譯是否正確，可以檢查整個系統(tǒng)中的COM+元件物件、IIS Web 應用程式以及單個的DLL檔l 使用方法：vbchkw2k [ /sc] or [dllname ]參數(shù)說明：1：/sc 掃描IIS（進程中），OOP Pooled、以及安裝在COM+元件和COM+目錄下的獨立的應用程式；（由於K/3系統(tǒng)相應的DLL比較多，可以把內(nèi)容輸出成一個日誌檔，然後在進行分析，方式在後面加上” “）2：dllname 掃描指定的DLL3：無 掃描IIS（進程中），OOP Pooled、以及安裝在COM+元件下的獨立的應用程式；l 示例命令：vbchkw2k /sc 結果：Scanning (PID:828) kdsvrmgrC:\WINNT\system32\KDCOM\ is fine... Retained In Memory :ON Unattended Execution :ON Retained In Memory :OFF Unattended Execution :OFF C:\WINNT\system32\KDCOM\ Please Repile! Retained In Memory :OFF Unattended Execution :OFF C:\WINNT\system32\ Please Repile! Retained In Memory :OFF Unattended Execution :OFF C:\Program Files\Kingdee\K/3ERP\ Please Repile!從上面的結果可以看出：在COM+，而且保持在記憶體中；。不要忘了查看 SQL Profiler 跟蹤檔、errorlog，或其他相關資訊，有助於解釋你在性能記錄所看到的現(xiàn)象。 l SQL Server Total Server Memory 持續(xù)飆高不一定是 memory leak。最後要注意的是不要利用 Windows NT 的 Perfmon 讀取 Windows 2000 Sysmon 產(chǎn)生的日誌檔當要分析記錄所得的資料時，尋找某些模式，以及不正常之高或低的計數(shù)值，這有助於瞭解什麼是“正?！敝?，對建立基線是有幫助的，如果一個計數(shù)器顯示某個問題，可尋找其他的證據(jù)以支持你的理論，例如：l % Process Time 的值持續(xù)很高，瓶頸不一定是在 CPU 。為不同的記錄 instance 配置不同的值域範圍(range)，若要突顯圖表中某個 instance 的線條，可以在下方區(qū)塊選到該線條後按快捷鍵 Ctrl+H。在查看資料時，應先繪製全部記錄的圖表，以瞭解整體的趨勢。若系統(tǒng)間有不同時區(qū)的差異，Sysmon 會做調(diào)整，Perfmon 則不會。過濾的結果將以逗號分隔的一般文字存檔，也就是默認給 Excel 看的 .csv 檔，所以結果輸出到 檔中，你可以直接通過 Excel 打開查看分析。要小心的是默認“Windows System Monitor”將 HTML 格式的配置檔是以 Unicode 存檔，“記事本”會依照原編碼格式也就是 Unicode 存檔，而 看不懂這種檔格式。 5. 保留你有興趣的計數(shù)器，將其餘的計數(shù)器刪掉，同時把所有的格式通通刪掉，只保留如下的格式屬性： [\\Computer]\Object[Parent/InstanceIndex]\Counter 若需要多個計數(shù)器，則每個名稱間以換行符號分開，範例如下： \\BYRON2003NB\Memory\Pages/sec \\BYRON2003NB\PhysicalDisk(_Total)\Avg. Disk Queue Length \\BYRON2003NB\Processor(_Total)\% Processor Time 其中 \\Computer 名稱可以省略。 3. 圖表上以滑鼠右鍵選擇“另存新檔”，格式為 HTML。使用 的步驟如下： 1. 查看日誌檔資料：打開先前抽取的 .blg 文件。若在 Windows 2000 則可以利用 Sysmon 的計畫任務，定時停掉並重起記錄，以分成多個日誌檔。日誌檔最大極限 1 gigabyte (GB)，而單一日誌檔太大也很難處理，可行的日誌檔大小應該在 100 megabytes (MB) 左右，建議取 50 MB。檢查記錄檔所花的硬碟空間。 一次記錄通常無法包含所有需要的資訊，可能要多次後續(xù)不同的記錄資料。 l 所有的 SQL Server 物件。初次記錄時，在不傷及性能的前提下，僅可能地抽取所有的物件，供你對整個系統(tǒng)有一個全面性的概觀。diskperf –y 39。另外，為減輕對電腦長期的影響，若沒有特殊需求，只要記錄 2 小時就好。 l 記錄1天 – 每 180 秒記錄一次。執(zhí)行性能監(jiān)視器時間要長到足以抓取到問題，一般粗略的配置綱要如下：l 記錄2小時 – 每 4 秒記錄一次。以較穩(wěn)定的方式抽取電腦完整的狀態(tài)，由於在事前你很難預料判斷瓶頸時，會需要哪些資料，所以儘量記錄所有的計數(shù)器5。因此當考慮加強中央處理器時，要看看是否是周邊設備的不足，導致CPU忙碌。CPU性能的重要性不用強調(diào)了吧，它慢，週邊設備再快都沒有用。因此建議將三種檔分別放在不同的硬碟上。 磁片子系統(tǒng)的性能不佳，也一定會讓 SQL Server 性能好不起來，畢竟它需要大量讀寫存在硬碟上資料庫內(nèi)的資料。例如有新的資料要放到屬性已滿的緩衝區(qū)，則 SQL Server 內(nèi)部負責將緩衝區(qū)屬性更新到硬碟的 LazyWriter 程式就需要持續(xù)地執(zhí)行，好更新緩衝區(qū)的資料，並釋放較沒有使用到的記憶體區(qū)塊，這會同時讓 CPU 與硬碟忙碌起來。SQL Server 是非常耗用記憶體的軟體，因為它凡用過的資料必先留在記憶體中，除非資源不足，否則不輕易從緩衝區(qū)清掉，讓資料庫的運行儘量少使用硬碟。而一旦採用遠端監(jiān)控，要先同步兩臺機器的時間才好比對結果。如果需要調(diào)校的電腦可能會當機，則要採用遠端記錄，避免資料未記錄到就掛了。除了一般的硬體，如記憶體、硬碟、中央處理器乃至於網(wǎng)路等系統(tǒng)提供的性能計數(shù)器外，大部分微軟提供的伺服器軟體在安裝完畢後，也會註冊它自身的性能計數(shù)器，而 SQL Server 會增加相當多類的性能計數(shù)器供你查核使用狀況，而這些性能物件皆以“SQLServer:”開頭。 l 抽取電腦變化的狀態(tài)，有基線以供比較是非常重要的，它讓你可以知道什麼是正常，而什麼不是。性能監(jiān)視器讓你獲得證據(jù)以完成： l 支持自己的假設，或是推翻結論另尋原因。而性能計數(shù)器代表的是一種指標，它本身不是問題，某些背後隱含的問題導致該指標的變化。我們在性能調(diào)校的過程中會一再地用它。 性能監(jiān)視器(Performance Monitor)Windows NT 之後所附的性能監(jiān)視器是顯示各種性能資料非常詳盡的工具。 C：抽取聚集信息。 X：排除錯誤日誌檔。此時，跟蹤檔案名稱仍維持原先的 和 。 O 導出檔案名稱：將 SQLDiag 的導出重新導向到指定的檔。密碼有區(qū)分大小寫。 P 密碼：上述帳號對應的密碼。若不指定 –I 選項，則連接至本機默認的執(zhí)行實例。 是一個相當容易執(zhí)行的工具程式，若要參照它的使用方式，可以進入“命令提示符”程式，轉到 所在的目錄下執(zhí)行 SQLDiag /?( 默認目錄是 系統(tǒng)磁碟機:\Program Files\Microsoft SQL Server\MSSQL\Binn)，以顯示各項參數(shù)，或是在 SQL Server 所附的“聯(lián)機文檔”利用 SQLDiag 關鍵字找尋使用的細節(jié)，URL 是：mk:MSITStore:C:\Program%20Files\Microsoft%20SQL%20Server\80\Tools\Books\ ::/以下簡述它各項參數(shù)的使用方式： ?：顯示使用說明。 獲取系統(tǒng)資訊是靠 工具程式取得系統(tǒng)的相關資訊，你可以直接執(zhí)行該工具程式以查看更豐富的資訊，如下圖： 點擊 主功能表的[檔] [導出]選項，可以將系統(tǒng)當前的各項資訊導出成文字檔案，供你日後參考。 l 通過 獲取系統(tǒng)的細節(jié)資料，這需要耗掉一些時間。 l 通過 DBCC INPUTBUFFER (spid) 獲取各進程正在執(zhí)行的命令。例如通過 waittime 欄位知道有哪些程式已經(jīng)等待很久，從 cpu、physical_io 以及 memusage 欄位可以看出哪些程式在耗 CPU、磁片輸出入或記憶體資源。當系統(tǒng)忙碌時，你可以通過它觀察到底有哪些程式在伺服器內(nèi)執(zhí)行，各用了多少資源等等。通過這個系統(tǒng)存儲過程會表列出所有的擴展存儲過程，你可以將它的輸出與一般安裝的 SQL Server 做個比較，看看是否有用戶自行安裝的擴展存儲過程，造成系統(tǒng)的不穩(wěn)定。 l 通過 sp_helpextendedproc 系統(tǒng)存儲過程獲取擴展存儲過程(extended stored procedures)的相關資訊。 l 通過 sp_helpdb 系統(tǒng)存儲過程獲取 SQL Server 執(zhí)行實例內(nèi)各資料庫的相關資訊。 l 通過 sp_who 系統(tǒng)存儲過程獲取當前登錄 SQL Server 執(zhí)行實例的用戶各項細節(jié)。 l 獲取相關程式庫(dll library)的版本資訊。當然，若有錯誤，也會存放在這個檔中，SQLDiag 默認會將這些 ErrorLog 檔一併放到輸出結果的檔內(nèi)。輸出的相關資料列述如下：l 獲取記錄檔，若是 SQL Server 2000 的版本，這些記錄檔默認是位於“系統(tǒng)磁碟機\Program Files\Microsoft SQL Server\MSSQL\LOG”目錄下，名稱為 ERRORLOG 及副檔名是數(shù)字的先前版本，如 、 一直到 等等，若版本是 SQL Server ，則這些記錄檔路徑默認是 系統(tǒng)磁碟機 \MSSQL7\log\。例如你觀察到 SQL Server 對某個查詢的回應遲緩，可能需要同時觀察系統(tǒng)硬體各項資源的使用，SQL Server 當時的鎖狀況，是否有錯誤發(fā)生等等，必須要互相參照，才容易找出禍首。它可以在同一時間、一次幫你收集相當多的資訊。 修改默認設置後，會提高中間層的併發(fā)性能。如果是以前版本的客戶可以直接修改中間層伺服器註冊表選項。四) 關於STA模式COM+元件線程數(shù)限制問題對於VB編寫的COM+元件，由於不能編譯為MTA線程模型，每個元件包進程的線程數(shù)默認為10個，也就是說同一個元件包中所有元件功能只能最多有十個同時運行。找到耗用資源較多的DLLHOST，找對應的PID(進程標示號)，根據(jù)PID在元件管理中可以找到對應的元件包，然後在對元件包下面尋找調(diào)用時間長的元件，把此元件的資訊和其他用戶操作資訊回饋到研發(fā)，可以定位到具體的功能。介面如下圖：二) 如何找到正在執(zhí)行的資源耗用多的組件有時候如果中間層的CPU或記憶體耗用很嚴重，由於在多個客戶的併發(fā)下有時候客戶很難發(fā)現(xiàn)是那一項操作引發(fā)了問題，這時候可以找一下那一個元件包中的哪一