性能測試結(jié)果分析

1、性能測試工程師根本上都能夠掌握利用測試工具來作負(fù)載、 壓力測試， 但多數(shù)人對怎樣去分 析工具收集到的測試結(jié)果感到無從下手， 下面我就把個人工作中的體會和收集到的有關(guān)資料 整理出來，希望能對大家分析測試結(jié)果有所幫助。 分析原那么：1. 具體問題具體分析這是由于不同的應(yīng)用系統(tǒng)，不同的測試目的，不同的性能關(guān)注點(diǎn)2. 查找瓶頸時按以下順序，由易到難。效勞器硬件瓶頸 -網(wǎng)絡(luò)瓶頸對局域網(wǎng)，可以不考慮-效勞器操作系統(tǒng)瓶頸參數(shù)配置 -中間件瓶頸參數(shù)配置，數(shù)據(jù)庫， web 效勞器等 -應(yīng)用瓶頸 SQL 語句、數(shù)據(jù) 庫設(shè)計(jì)、業(yè)務(wù)邏輯、算法等注：以上過程并不是每個分析中都需要的，要根據(jù)測試目的和要求來確定分析的深度

2、。 對一些要求低的，我們分析到應(yīng)用系統(tǒng)在將來大的負(fù)載壓力并發(fā)用戶數(shù)、數(shù)據(jù)量下，系 統(tǒng)的硬件瓶頸在哪兒就夠了。3 分段排除法 很有效分析的信息來源：1 根據(jù)場景運(yùn)行過程中的錯誤提示信息2 根據(jù)測試結(jié)果收集到的監(jiān)控指標(biāo)數(shù)據(jù)一錯誤提示分析分析實(shí)例：1 Error: Failed to connect to server “ .30:8080" : 10060 Conn ectionError: timed out Error: Server “ .30" has shut dow n the connection prematurely分析：A 、應(yīng)用效勞死掉。小用戶時：程序上的

3、問題。程序上處理數(shù)據(jù)庫的問題B、應(yīng)用效勞沒有死應(yīng)用效勞參數(shù)設(shè)置問題例：在許多客戶端連接 Weblogic 應(yīng)用效勞器被拒絕，而在效勞器端沒有錯誤顯示，那么 有可能是 Weblogic 中的 server 元素的 AcceptBacklog 屬性值設(shè)得過低。如果連接時收到 connection refused 消息，說明應(yīng)提高該值，每次增加25C、數(shù)據(jù)庫的連接(1、在應(yīng)用效勞的性能參數(shù)可能太小了2、數(shù)據(jù)庫啟動的最大連接數(shù) 跟硬件的內(nèi)存有關(guān) )2 Error: Page download timeout (120 seconds) has expired 分析：可能是以下原因造成A 、應(yīng)用效勞參數(shù)

4、設(shè)置太大導(dǎo)致效勞器的瓶頸B、頁面中圖片太多C、在程序處理表的時候檢查字段太大多二監(jiān)控指標(biāo)數(shù)據(jù)分析1最大并發(fā)用戶數(shù)： 應(yīng)用系統(tǒng)在當(dāng)前環(huán)境硬件環(huán)境、網(wǎng)絡(luò)環(huán)境、軟件環(huán)境參數(shù)配置 下能承受的最大并發(fā) 用戶數(shù)。在方案運(yùn)行中，如果出現(xiàn)了大于 3 個用 戶的業(yè)務(wù)操作失敗，或出現(xiàn)了效勞器 shutdown 的情況，那么說明在當(dāng)前環(huán)境下，系統(tǒng)承受不 了當(dāng)前并發(fā)用戶的負(fù)載壓力， 那么最大并發(fā)用戶數(shù)就是前一個沒有出現(xiàn)這種現(xiàn)象的并發(fā)用戶 數(shù)。如果測得的最大并發(fā)用戶數(shù)到達(dá)了性能要求， 且各效勞器資源情況良好， 業(yè)務(wù)操作響應(yīng) 時間也到達(dá)了用戶要求，那么 OK 。否那么，再根據(jù)各效勞器的資源情況和業(yè)務(wù)操作響應(yīng)時間 進(jìn)一步分

5、析原因所在。2業(yè)務(wù)操作響應(yīng)時間： 分析方案運(yùn)行情況應(yīng)從平均事務(wù)響應(yīng)時間圖和事務(wù)性能摘要圖開始。使用“事務(wù)性能 摘要圖，可以確定在方案執(zhí)行期間響應(yīng)時間過長的事務(wù)。細(xì)分事務(wù)并分析每個頁面組件的性能。 查看過長的事務(wù)響應(yīng)時間是由哪些頁面組件引起 的？問題是否與網(wǎng)絡(luò)或效勞器有關(guān)？如果效勞器耗時過長， 請使用相應(yīng)的效勞器圖確定有問題的效勞器度量并查明效勞器性能 下降的原因。如果網(wǎng)絡(luò)耗時過長，請使用“網(wǎng)絡(luò)監(jiān)視器圖確定導(dǎo)致性能瓶頸的網(wǎng)絡(luò)問題3效勞器資源監(jiān)控指標(biāo)：內(nèi)存：1 UNIX資源監(jiān)控中指標(biāo)內(nèi)存頁交換速率 Paging rate，如果該值偶爾走高，說明當(dāng)時有線 程競爭內(nèi)存。如果持續(xù)很高，那么內(nèi)存可能是瓶頸

6、。也可能是內(nèi)存訪問命中率低。2 Windows 資源監(jiān)控中， 如果 ProcessPrivate Bytes 計(jì)數(shù)器和 ProcessWorking Set 計(jì)數(shù)器的值 在長時間內(nèi)持續(xù)升高，同時 MemoryAvailable bytes 計(jì)數(shù)器的值持續(xù)降低，那么很可能存在內(nèi) 存泄漏。內(nèi)存資源成為系統(tǒng)性能的瓶頸的征兆 : 很高的換頁率 (high pageout rate);進(jìn)程進(jìn)入不活動狀態(tài) ; 交換區(qū)所有磁盤的活動次數(shù)可高 ;可高的全局系統(tǒng) CPU 利用率 ; 內(nèi)存不夠出錯 (out of memory errors)處理器：1 UNIX 資源監(jiān)控 Windows 操作系統(tǒng)同理中指標(biāo) CP

7、U 占用率 CPU utilization ，如果該 值持續(xù)超過95%，說明瓶頸是 CPU?？梢钥紤]增加一個處理器或換一個更快的處理器。如 果效勞器專用于 SQL Server,可接受的最大上限是80-85%合理使用的范圍在 60%至 70%。2 Windows 資源監(jiān)控中，如果 SystemProcessor Queue Length 大于 2，而處理器利用率Processor Time一直很低，那么存在著處理器阻塞。CPU 資源成為系統(tǒng)性能的瓶頸的征兆 :很慢的響應(yīng)時間 (slow response time)CPU 空閑時間為零 (zero percent idle CPU)過高的用戶占

8、用 CPU時間(high percent user CPU) 過高的系統(tǒng)占用 CPU 時間 (high percent system CPU) 長時間的有很長的運(yùn)行進(jìn)程隊(duì)列 (large run queue size sustained over time)磁盤 I/O ：1 UNIX 資源監(jiān)控 Windows 操作系統(tǒng)同理中指標(biāo)磁盤交換率 Disk rate ，如果該參數(shù)值 一直很高，說明 I/O 有問題?？煽紤]更換更快的硬盤系統(tǒng)。2 Windows 資源監(jiān)控中，如果 Disk Time 和 Avg.Disk Queue Length 的值很高，而 Page Reads/sec頁面讀取操作速

9、率很低，那么可能存在磁盤瓶徑。I/O 資源成為系統(tǒng)性能的瓶頸的征兆 :過高的磁盤利用率 (high disk utilization) 太長的磁盤等待隊(duì)列 (large disk queue length)等待磁盤 I/O 的時間所占的百分率太高 (large percentage of time waiting for disk I/O) 太高的物理 I/O 速率:large physical I/O rate(not sufficient in itself) 過低的緩存命中率 (low buffer cache hit ratio(not sufficient in itself) 太長

10、的運(yùn)行進(jìn)程隊(duì)列，但 CPU 卻空閑 (large run queue with idle CPU)4數(shù)據(jù)庫效勞器：SQL Server 數(shù)據(jù)庫：1 SQLServer 資源監(jiān)控中指標(biāo)緩存點(diǎn)擊率 Cache Hit Ratio ，該值越高越好。如果持續(xù)低于 80%，應(yīng)考慮增加內(nèi)存。2如果Full Scans/sec全表掃描/秒計(jì)數(shù)器顯示的值比1或2高，那么應(yīng)分析你的查詢以確定是否確實(shí)需要全表掃描，以及 SQL 查詢是否可以被優(yōu)化。3 Number of Deadlocks/sec(死鎖的數(shù)量/秒):死鎖對應(yīng)用程序的可伸縮性非常有害，并且會導(dǎo)致惡劣的用戶體驗(yàn)。該計(jì)數(shù)器的值必須為0。4 Lock R

11、equests/sec(鎖請求/秒)，通過優(yōu)化查詢來減少讀取次數(shù)，可以減少該計(jì)數(shù)器的值。Oracle 數(shù)據(jù)庫:1 如果自由內(nèi)存接近于 0 而且?guī)炜齑婊驍?shù)據(jù)字典快存的命中率小于 0.90，那么需要增加 SHARED_POOL_SIZE 的大小?？齑婀蚕?SQL 區(qū)和數(shù)據(jù)字典快存的命中率:select(sum(pins-reloads)/sum(pins) from v$librarycache;select(sum(gets-getmisses)/sum(gets) from v$rowcache;自由內(nèi)存：select * from v$sgastat where name= 'fre

12、e memory ' ;2 如果數(shù)據(jù)的緩存命中率小于0.90，那么需要加大 DB_BLOCK_BUFFERS 參數(shù)的值 單位：塊。緩沖區(qū)高速緩存命中率：select name,value from v$sysstat where name in (' db block gets ', consistent gets ' ,'physical reads ' ) ;Hit Ratio = 1-(physical reads / ( db block gets + consistent gets)3 如果日志緩沖區(qū)申請的值較大，那么應(yīng)加大 LOG_B

13、UFFER 參數(shù)的值。 日志緩沖區(qū)的申請情況 ：select name,value from v$sysstat where name = redo log space requests4 如果內(nèi)存排序命中率小于 0.95，那么應(yīng)加大 SORT_AREA_SIZE 以防止磁盤排序 內(nèi)存排序命中率 ：select round(100*b.value)/decode(a.value+b.value), 0, 1, (a.value+b.value), 2)from v$sysstat a, v$sysstat b where =' sorts (disk)' and b

14、.name= ' sorts (memory) '注：上述 SQL Server 和 Oracle 數(shù)據(jù)庫分析，只是一些簡單、根本的分析，特別是 Oracle 數(shù) 據(jù)庫的分析和優(yōu)化，是一門專門的技術(shù)，進(jìn)一步的分析可查相關(guān)資料。性能測試的結(jié)果分析是性能測試的重中之重。在實(shí)際工作中，由于測試的結(jié)果分析比擬復(fù)雜、需要具備很多相關(guān)的專業(yè)知識， 因此常常會感覺拿到數(shù)據(jù)不知從何下手。 這也是我學(xué)習(xí) 性能測試過程中感覺比擬為難和棘手的事，為此我在研讀了? WEB 性能測試實(shí)戰(zhàn)?后特作了以 下筆記，這里只是書中第 4 章 WEB 應(yīng)用程序性能分析的一局部，貼出來希望和大家共同討論：性能分析的根

15、底知識：TPS每秒鐘處理的交易數(shù)、點(diǎn)1. 幾個重要的性能指標(biāo)：相應(yīng)時間、吞吐量、吞吐率、擊率等。2. 系統(tǒng)的瓶頸分為兩類：網(wǎng)絡(luò)的和效勞器的。效勞器瓶頸主要涉及：應(yīng)用程序、WEB 效勞器、數(shù)據(jù)庫效勞器、操作系統(tǒng)四個方面。3. 常規(guī)、粗略的性能分析方法：當(dāng)增大系統(tǒng)的壓力或增加并發(fā)用戶數(shù)時，吞吐率和TPS的變化曲線呈大體一致，那么系統(tǒng)根本穩(wěn)定； 假設(shè)壓力增大時，吞吐率的曲線增加到一定程度后出現(xiàn)變化緩慢，甚至平坦，很 可能是網(wǎng)絡(luò)出現(xiàn)帶寬瓶頸，同理假設(shè)點(diǎn)擊率 /TPS 曲線出現(xiàn)變化緩慢或者平坦，說明效勞器開始出 現(xiàn)頸。4. 作者提出了如下的性能分析根本原那么，此原那么本人十分贊同：由外而內(nèi)、由表及里、層

16、層深入應(yīng)用此原那么，分析步驟具體可以分為以下三步： 第一步：將得到的響應(yīng)時間和用戶對性能的期望值比擬確定是否存在瓶頸；第二步：比擬Tn網(wǎng)絡(luò)響應(yīng)時間和 Ts效勞器響應(yīng)時間可以確定瓶頸發(fā)生在網(wǎng)絡(luò)還 是服務(wù)器；第三步：進(jìn)一步分析，確定更細(xì)組件的響應(yīng)時間，直到找出發(fā)生性能瓶頸的根本原因。以 WEB 應(yīng)用程序?yàn)槔齺砜聪戮唧w的分析方法：1.用戶事務(wù)分析：a. 事務(wù)綜述圖(Transaction Summary ):以柱狀圖的形式表現(xiàn)了用戶事務(wù)執(zhí)行的成功與失敗。通過分析成功與失敗的數(shù)據(jù)可以直接判斷出系統(tǒng)是否運(yùn)行正常。 假設(shè)失敗的事務(wù)非常 多，那么說明系統(tǒng)發(fā)生了瓶頸或者程序在執(zhí)行過程中發(fā)生了問題。b. 事務(wù)平

17、均響應(yīng)時間分析圖 Average Transaction Response Time：該圖顯示在測試場景運(yùn)行期間的每一秒內(nèi)事務(wù)執(zhí)行所用的平均時間， 還顯示了測試場景運(yùn)行時間內(nèi)各個 事務(wù)的最大值、 最小值和平均值。 通過它可以分析系統(tǒng)的性能走向。 假設(shè)所有事務(wù)響應(yīng)時間根本 成一條曲線， 那么說明系統(tǒng)性能根本穩(wěn)定； 否那么如果平均事務(wù)響應(yīng)時間逐漸變慢， 說明性能有下降趨 勢，造成性能下降的原因有可能是由于內(nèi)存泄漏導(dǎo)致。c. 每秒通過事務(wù)數(shù)分析圖Transaction per Second即TPS：顯示在場景運(yùn)行的每一秒中，每個事 務(wù)通過、失敗以及停止的數(shù)量。通過它可以確定系統(tǒng)在任何給定時刻的實(shí)際事

18、務(wù)負(fù)載。 假設(shè)隨著測試的進(jìn)展， 應(yīng)用系統(tǒng)在單位時間內(nèi)通過的事務(wù)數(shù)目在減少， 那么說明效勞器 出現(xiàn)瓶頸。d. 每秒通過事務(wù)總數(shù)分析圖 Total Transactions per Second：顯示場景運(yùn)行的每一秒中，通過、失敗以及停止的事務(wù)總數(shù)。假設(shè)在同等壓力下，曲線接近直線，那么性能基 本趨于穩(wěn)定； 假設(shè)在單位時間內(nèi)通過的事務(wù)總量越來越少， 即整體性能下降。 原因可能是內(nèi)存泄漏 或者程序中的缺陷。e. 事務(wù)性能摘要圖Transaction Performanee Summary：顯示方案中所有事務(wù)的最小、最大平均執(zhí)行時間，可以直接判斷響應(yīng)時間是否符合客戶要求重點(diǎn)關(guān)注事務(wù)平均、 最大執(zhí)行時間。

19、f. 事務(wù)響應(yīng)時間與負(fù)載分析圖Transaction Response Time Under load:通過該圖可以看出在任一時間點(diǎn)事務(wù)響應(yīng)時間與用戶數(shù)目的關(guān)系， 從而掌握系統(tǒng)在用戶并發(fā)方面 的性能數(shù)據(jù)。g. 事務(wù)響應(yīng)時間百分比圖Transaction Response Time(percentile):該圖是根據(jù)測試結(jié)果進(jìn)行分析而得到的綜合分析圖。 分析該圖應(yīng)從整體出發(fā)， 假設(shè)可能事務(wù)的 最大響應(yīng)時間很長，但如果大多數(shù)事務(wù)具有可接受的響應(yīng)時間，那么系統(tǒng)的性能是符合。h. 事務(wù)響應(yīng)時間分布情況圖Transaction Response Time (Distribution):該圖顯示了測試過程

20、中不同響應(yīng)時間的事務(wù)數(shù)量。 假設(shè)系統(tǒng)預(yù)先定義了相關(guān)事務(wù)可以接受的最 小和最大事務(wù)響應(yīng)時間，那么可以使用此圖確定系統(tǒng)性能是否在接受范圍內(nèi)。分析到這一步，只能大概判斷出瓶頸可能會出在那，要具體定位瓶頸還需要更深入的分析。沒有貼圖，看起來有點(diǎn)費(fèi)力，如果你對這些圖都比擬了解，應(yīng)該是比擬簡單的分析原那么：? 具體問題具體分析這是由于不同的應(yīng)用系統(tǒng)，不同的測試目的，不同的性能關(guān)注點(diǎn)? 查找瓶頸時按以下順序，由易到難。效勞器硬件瓶頸 -網(wǎng)絡(luò)瓶頸對局域網(wǎng)，可以不考慮-效勞器操作系統(tǒng)瓶頸參數(shù)配置-中間件瓶頸參數(shù)配置，數(shù)據(jù)庫，web效勞器等-應(yīng)用瓶頸SQL語句、數(shù)據(jù)庫設(shè)計(jì)、業(yè)務(wù)邏輯、算法等 注：以上過程并不是每個

21、分析中都需要的， 要根據(jù)測試目的和要求來確定分析的深度。 對一 些要求低的，我們分析到應(yīng)用系統(tǒng)在將來大的負(fù)載壓力并發(fā)用戶數(shù)、數(shù)據(jù)量下，系統(tǒng)的 硬件瓶頸在哪兒就夠了。? 分段排除法 很有效 分析的信息來源：?1 根據(jù)場景運(yùn)行過程中的錯誤提示信息?2 根據(jù)測試結(jié)果收集到的監(jiān)控指標(biāo)數(shù)據(jù) 一錯誤提示分析分析實(shí)例：1 ?Error: Failed to connect to server“ paymer0b6(heConnection?Error: timed out Error: Server“ uSer.baihehut down the connection prematurely分析：?A、應(yīng)用

22、效勞死掉。小用戶時：程序上的問題。程序上處理數(shù)據(jù)庫的問題?B、應(yīng)用效勞沒有死應(yīng)用效勞參數(shù)設(shè)置問題例：在許多客戶端連接 Weblogic 應(yīng)用效勞器被拒絕，而在效勞器端沒有錯誤顯示，那么有 可能是 Weblogic 中的 server 元素的 AcceptBacklog 屬性值設(shè)得過低。如果連接時收到 connection refused 消息，說明應(yīng)提高該值，每次增加 25?C、數(shù)據(jù)庫的連接(1、在應(yīng)用效勞的性能參數(shù)可能太小了2、數(shù)據(jù)庫啟動的最大連接數(shù)跟硬件的內(nèi)存有關(guān) )2 Error: Page download timeout (120 seconds) has expired分析：可能是

23、以下原因造成?A、應(yīng)用效勞參數(shù)設(shè)置太大導(dǎo)致效勞器的瓶頸?B、頁面中圖片太多?C 、在程序處理表的時候檢查字段太大多 二監(jiān)控指標(biāo)數(shù)據(jù)分析1最大并發(fā)用戶數(shù)： 應(yīng)用系統(tǒng)在當(dāng)前環(huán)境硬件環(huán)境、網(wǎng)絡(luò)環(huán)境、軟件環(huán)境參數(shù)配置下能承受的最大并發(fā)用戶數(shù)。在方案運(yùn)行中，如果出現(xiàn)了大于 3個用戶的業(yè)務(wù)操作失敗，或出現(xiàn)了效勞器 shutdown 的 情況， 那么說明在當(dāng)前環(huán)境下， 系統(tǒng)承受不了當(dāng)前并發(fā)用戶的負(fù)載壓力， 那么最大并發(fā)用戶數(shù) 就是前一個沒有出現(xiàn)這種現(xiàn)象的并發(fā)用戶數(shù)。如果測得的最大并發(fā)用戶數(shù)到達(dá)了性能要求，且各效勞器資源情況良好，業(yè)務(wù)操作響應(yīng) 時間也到達(dá)了用戶要求，那么 OK 。否那么，再根據(jù)各效勞器的資源情

24、況和業(yè)務(wù)操作響應(yīng)時間進(jìn)一步分析原因所在。2業(yè)務(wù)操作響應(yīng)時間：? 分析方案運(yùn)行情況應(yīng)從平均事務(wù)響應(yīng)時間圖和事務(wù)性能摘要圖開始。使用 “事務(wù)性能摘 要圖，可以確定在方案執(zhí)行期間響應(yīng)時間過長的事務(wù)。? 細(xì)分事務(wù)并分析每個頁面組件的性能。查看過長的事務(wù)響應(yīng)時間是由哪些頁面組件引起 的？問題是否與網(wǎng)絡(luò)或效勞器有關(guān)？? 如果效勞器耗時過長， 請使用相應(yīng)的效勞器圖確定有問題的效勞器度量并查明效勞器性能 下降的原因。如果網(wǎng)絡(luò)耗時過長，請使用 “網(wǎng)絡(luò)監(jiān)視器 圖確定導(dǎo)致性能瓶頸的網(wǎng)絡(luò)問題2-5-10 原那么：簡單說，就是當(dāng)用戶能夠在 2 秒以內(nèi)得到響應(yīng)時，會感覺系統(tǒng)的響應(yīng)很快；當(dāng) 用戶在 2-5 秒之間得到響應(yīng)時

25、，會感覺系統(tǒng)的響應(yīng)速度還可以；當(dāng)用戶在5-10 秒以內(nèi)得到響應(yīng)時，會感覺系統(tǒng)的響應(yīng)速度很慢，但是還可以接受；而當(dāng)用戶在超過10 秒后仍然無法得到響應(yīng)時，會感覺系統(tǒng)糟透了，或者認(rèn)為系統(tǒng)已經(jīng)失去響應(yīng)，而選擇離開這個 Web 站點(diǎn)， 或者發(fā)起第二次請求3效勞器資源監(jiān)控指標(biāo)：內(nèi)存：1 UNIX 資源監(jiān)控中指標(biāo)內(nèi)存頁交換速率Paging rate ，如果該值偶爾走高，說明當(dāng)時有線程競爭內(nèi)存。如果持續(xù)很高，那么內(nèi)存可能是瓶頸。也可能是內(nèi)存訪問命中率低。2 Windows 資源監(jiān)控中， 如果 ProcessPrivate Bytes 計(jì)數(shù)器和 ProcessWorking Set 計(jì)數(shù)器的值 在長時間內(nèi)持續(xù)

26、升高，同時 MemoryAvailable bytes 計(jì)數(shù)器的值持續(xù)降低，那么很可能存在內(nèi) 存泄漏。內(nèi)存資源成為系統(tǒng)性能的瓶頸的征兆 :很高的換頁率 (high pageout rate);進(jìn)程進(jìn)入不活動狀態(tài) ; 交換區(qū)所有磁盤的活動次數(shù)可高 ;可高的全局系統(tǒng) CPU 利用率 ;內(nèi)存不夠出錯 (out of memory errors)處理器：1 UNIX 資源監(jiān)控 Windows 操作系統(tǒng)同理中指標(biāo) CPU 占用率 CPU utilization ，如果該值持續(xù)超過95%，說明瓶頸是 CPU?？梢钥紤]增加一個處理器或換一個更快的處理器。如果效勞器專用于 SQL Server,可接受的最大上

27、限是 80-85%合理使用的范圍在 60%至 70%。2 Windows 資源監(jiān)控中，如果 SystemProcessor Queue Length 大于 2，而處理器利用率Processor Time一直很低，那么存在著處理器阻塞。CPU 資源成為系統(tǒng)性能的瓶頸的征兆 :很慢的響應(yīng)時間 (slow response time)CPU 空閑時間為零 (zero percent idle CPU)過高的用戶占用 CPU時間(high percent user CPU)過高的系統(tǒng)占用 CPU 時間 (high percent system CPU)長時間的有很長的運(yùn)行進(jìn)程隊(duì)列 (large run queue size sustained over time)磁盤 I/O ：1 UNIX 資源監(jiān)控 Windows 操作系統(tǒng)同理中指標(biāo)磁盤交換率 Disk rate ，如果該參數(shù)值 一直很高，說明 I/O 有問題。可考慮更換更快的硬盤系統(tǒng)。2 Windows 資源監(jiān)控中，如果 Disk Tim