核心實驗：監控並分析Windows和Linux關鍵性能指標

實驗簡介

「巧婦難為無米之炊」，對於性能測試來說，如果沒有足夠的監控數據，我們則無從對其進行分析，也不能很好地定位性能瓶頸。所以，本節實驗將主要為大家講解如何利用Windows和Linux操作系統下的一些工具，完成對關鍵性能指標的監控。

實驗目的

（1）深刻理解操作系統常用的關鍵性能指標的作用。

（2）能夠自主設計實驗完成對性能指標的監控與確認。

（3）熟練使用Windows自帶的性能監控工具實施指標監控。

（4）熟練使用Linux自帶的性能監控工具實施指標監控。

（5）熟練使用NMon監控工具完成對Linux環境下的性能指標監控。

實驗流程

1. 操作系統的關鍵性能指標

操作系統作為應用系統運行的載體，其作用不言而喻。所以對於一個應用系統的性能消耗情況，通過監控操作系統底層的性能指標，基本上可以對系統的性能情況有一個全面的掌握。通常情況下，對於一個軟體系統的運行來說，我們通常監控下面一系統操作系統級指標：

（1） CPU使用率（%Processer Time）：決定了系統在高負載情況下消耗CPU的情況。CPU是一台伺服器的心臟，也為多線程運行提供了底層支持。而伺服器在處理高並發請求時，也都是依靠線程來完成，所以線程的使用對CPU的消耗是顯而易見的。另外一個方面，任何一個系統都會存在大量的運算，都需要利用CPU提供運算支持。所以基本上很多系統的CPU都容易成為性能瓶頸。

（2） CPU隊列長度（%Processer Time）：當CPU忙不過來的時候，就會產生很多排隊等待CPU資源的處理任務。隊列越長說明CPU越忙。

（3） 可用內存數（Available Mbytes）：可用的內存大小，單位為兆位元組。這是一個相對簡單的指標，可用內存數越大，說明內存不是問題。基本上來說目前內存都不太可能成為瓶頸。因為我們增加內存的成本相對較低。

（4） 頁交換頻率（Page/sec）：內存與虛擬內存（硬碟）之間進行數據交換（俗稱頁交換）的頻率，越低越好。這是一個歷史遺留問題，在早期的計算機系統中，內存容量都很小，經常出現內存不夠用的情況。但是一個系統的程序都是運行於內存中的，如果內存不夠則無法運行。所以系統設計人員想到了一個辦法，利用硬碟來偽裝成內存。當內存實在不夠用的時候，就從硬碟中切出一塊空間來專門用於虛擬內存，將一些暫時不使用但是又不能清除的內存數據交換到這塊虛擬內存的硬碟空間里臨時保存起來。這樣，就會存在物理內存與虛擬內存進行數據交換的過程。但是由於硬碟的讀寫速度實在太慢（相比內存來說，基本上慢至少100倍左右，此處指傳統的機械硬碟，固態硬碟會比機械硬碟快5倍左右，當然，不同的設備和介面規格，速度差異也不小），所以我們應該盡量減少虛擬內存的使用，進而減少頁交換的頻率，提升程序的運行效率。只要可用內存數量夠，建議可以調高緩存來降低其值。

在Windows的系統安裝盤（比如C：盤）下存在一個系統級隱藏文件叫：「pagefile.sys」，或者在Linux當中的特殊分區「/swap」，都是硬碟專門切分出來的一塊用於虛擬內存的專屬空間。但是為什麼是「頁交換」呢，因為在內存中，管理一塊內存空間的單位稱為「頁」，由此得名。

（5） 設置虛擬內存大小：通常情況下，操作系統為默認幫我們分配虛擬內存的大小，通常是物理內存的1.5到2倍，但是這是可以修改的。在Linux中，我們只需要簡單的調整「/swap」分區的大小即可。在Windows中，我們可以打開「我的電腦」->「屬性」->「高級系統設置」打開系統設置對話框，在「高級」選項卡的性能「設置」中打開「性能選項」，在「高級」選項卡中打開虛擬內存的「更改設置」，並調整為手工設置即可。設置完成後重啟電腦，便可以生效，這個設置大小就是「pagefile.sys」的文件大小。如下圖所示：

（6） 磁碟使用率（% Disk Time）：類似於CPU使用率，硬碟處於讀寫等工作狀態所佔的比例。該值越大，表示硬碟越忙，說明硬碟有可能會成為瓶頸。比如Web伺服器會大量讀取一些靜態資源文件，如圖片，JS文件或CSS文件等，或者在資料庫中頻繁操作硬碟上的數據文件等，都會容易導致硬碟使用率飆高，引起一些性能問題。對於硬碟的性能瓶頸，標準的解決方案就是有效利用緩存，來緩解硬碟的讀寫壓力。

（7） 磁碟隊列長度（Avg.Disk Queue Length）：類似於CPU隊列長度，當磁碟忙不過來的時候，則會有讀寫隊列產生，一般只要是在個位數，瞬間的隊列是正常的。

（8） 網路帶寬消耗：任何客戶端的請求和伺服器端的響應，都需要經過網路進行傳輸，所以網路帶寬是非常容易出現瓶頸的。我們在進行性能測試時，對網路帶寬的監控通常關注網卡每秒鐘接收到的數據（Bytes Received/sec）和每秒鐘傳輸出去的數據（Bytes Sent/sec），如果該數據與網路帶寬相當，則說明帶寬已經是瓶頸了。目前對於帶寬要求最高的，主要是視頻類網站，圖片類網站（一些電商網站中的圖片也非常多）或者資源下載站點等。這類系統的性能瓶頸基本上都是由帶寬導致的，而在互聯網上，帶寬的租用是非常昂貴的。也正因為這樣，我們才會一直致力於研究更優的演算法來對圖片，文件或者視頻進行壓縮。比如圖片壓縮演算法JPEG-2000，文件壓縮演算法GZip，或者視頻壓縮演算法H.265等。但是這裡仍然存在一個問題，越高效的壓縮演算法，意味著越消耗CPU資源，無論是壓縮還是解壓縮過程均是這樣的。這是一個無法兼得的情況，我們必須尋找平衡。

2. 關於緩存的進一步解釋

我們在性能測試部分大量提到了「緩存」這個東西，那麼到底緩存指哪些層面，如何有效地利用好「緩存」，目前常見的一些緩存應用有哪些呢？

（1） 什麼是緩存？緩存其實是一個很泛的概念，並不特指內存。比如在瀏覽器的臨時文件目錄中保存的網頁靜態資源，也可以稱之為瀏覽器緩存，但是這些資源卻是保存在硬碟上的。所以，我們應該換一個角度來理解緩存：充分利用更快的存儲設備，以緩解更慢的存儲設備的處理壓力，並且盡量不要因為慢速設備而拖了整個系統的後腿。

（2） 常見的一此存儲設備的速度：通常情況下一根標準DDR3內存條的讀寫速度大約在10GB/s左右（當然，不同廠商的不同規格的內存條會有差異）。而一塊機械硬碟的讀寫速度，平均可能就只有不到100MB/s，如果是隨機讀取一些小文件，速度會更慢。固態硬碟雖然比機械硬碟快（目前最新固態硬碟的實際讀寫速度平均來說500MB/s是個極限了已經），所以，很多時候，系統慢，硬碟和CPU通常是很重要的原因，內存反而不太容易成為瓶頸。另外一方面，機械設備的老化，導致數據傳輸效率受損也是原因之一。其實，在計算機系統中，存在各種各樣的緩存，內存其實並不是最快的存儲設置。最快的存儲設置是集成在CPU當中的一級緩存，二級緩存和三級緩存。筆者利用AIDA64（早期名叫Everest）這個工具對自己的電腦進行了一下內存和CPU緩存的測試，其速度如下：

我們可以看到，筆者電腦的內存讀寫速度平均算下來差不多有19GB/s，而當前i5的CPU一級緩存的讀取速度更是喪心病狂地達到了192GB/s，當然，一級緩存的造價是非常昂貴的，筆者的這台CPU的一級緩存只有「128KB」，已經算是較大的了。事實上，我們可以這樣理解，針對一台電腦的四個核心組成部分：「CPU，內存，硬碟，網路」來說，硬碟是網路的緩存，內存是硬碟的緩存，CPU緩存是內存的緩存。而通常，一個系統運行的I/O路徑也遵循上述順序。所以，對於CPU來說，內存的處理速度還是太慢了，所以直接集成一二三級緩存，來緩解CPU與內存處理速度上的差異。

下圖是筆者電腦上的一塊相對較老的固態硬碟，在針對8M大文件進行線性讀取（這是硬碟讀取文件時速度最快的組合）時的速度，平均速度只有193MB/s，筆者另外一台使用PCI-e介面的固態硬碟的電腦，其速度也就是450MB/s左右，也已經算是很快的固態硬碟了。而針對4K小文件進行隨機讀取（這是硬碟讀取文件時速度最慢的組合），只有大約40MB/s，比起機械硬碟來說，固態硬碟的強項就是小文件的處理，這已經是比較理想的狀態了。

（3） Web伺服器緩存：通常情況下，對於Web伺服器來說，使用硬碟最多的情況就是讀取伺服器端的靜態資源文件，如圖片，CSS文件，JS腳本等。這些靜態資源都是保存在硬碟中的，每一次情況都會讀取這些資源。所以如果我們設置更大的緩存，將這些靜態資源直接緩存在伺服器的內存中，則可以減少對硬碟的讀寫。比如在Apache中，我們可以啟用「mod_cache」這個模塊來有效地使用緩存。

（4） 資料庫伺服器緩存：對於資料庫伺服器來說，則更加依賴硬碟的性能。由於現在的關係型資料庫均是將數據文件保存在硬碟中，每一次執行SQL時，都可能會讀寫硬碟數據。所以，對於一台資料庫伺服器來說，硬碟的性能一定要好。也正因為如此，資料庫伺服器也同樣為我們提供了緩存策略，可以讓我們把一些已經查詢過的數據保存到內存中，供下次查詢時直接使用。但是，通常對於資料庫更新時，為了保存數據的同步，通常並不建議通過緩存來更新，而是直接更新到數據文件中。這就必然會牽涉到大量的寫硬碟操作。所以，在資料庫性能指標中有一個很特別的指標叫「SQL命中率」，這個指標越高，說明緩存起的作用越大。

（5） 緩存伺服器：除了資料庫自身的一些性能參數的設置外，目前在資料庫領域，比較流行的緩存伺服器是Redis，這是一種鍵值對的緩存伺服器。可以靈活地設置緩存策略，也支持將已經查詢過的數據保存在緩存中，如果下次查詢到相同的數據，則直接命中，不需要再經過資料庫伺服器來進行處理，直接把結果從Redis中返回給請求端。

（6） 內存型資料庫：其實Redis本身就可以認為是一個內存型資料庫，除此之外，目前市面上比較流行的內存型資料庫有Timesten，AltiBase，Extreme，CacheDB等。其基本特點就是將資料庫直接載入到內存當中來運行。但是目前這些資料庫還沒有辦法進行全面應用最主要的原因有兩點：一是應用系統的遷移成本巨大，二是其數據的高可用性考慮。因為內存一旦斷電，數據蕩然無存。雖然各內存型資料庫廠商都提供了很不錯的解決方案，一些傳統的觀念仍然在影響著企業的決定。最後的結局就是，小系統不需要用，因為資料庫沒有什麼瓶頸，大系統不敢用，因為數據重於一切。

（7） 線程池和連接池：線程池和連接池是網路伺服器中必備的兩種提升性能的方法。線程池的使用，主要用於減少線程不停地創建又銷毀這些無效操作，讓線程可以重複使用而不會被銷毀。就像連接池的使用一樣，盡量避免網路連接的頻繁創建又斷開，把有限的資源使用到處理業務上，而不是建立連接，創建線程這些事情上。那是不是線程池或連接池越多越好呢，當然，如果CPU資源夠的話，理論上來說是這樣的。但是事情都有兩面性，特別是對於多層伺服器架構來說，我們必須要考慮到每一層伺服器在處理能力上的協調。瓶頸永遠不會產生在高配置的電腦上，整個系統中最弱的環境才會導致瓶頸。舉個簡單的例子，CPU即使很強悍，能夠同時處理的請求非常多，但是網路帶寬能不能處理這麼大的吞吐量呢？如果不行，那麼CPU再強悍也是枉然。

3. 關於硬碟的性能

硬碟分為固態硬碟和機械硬碟，通常影響硬碟的處理主要由三個方面構成：

（1） 硬碟的內置緩存。通常情況下，固態硬碟的高速緩存可以達到256MB甚至更多，而機械硬碟的高級緩存通常只有32MB或者最多64MB，所以固態硬碟快於機械硬碟，調整緩存也是一個影響因素。當然，更高的高速緩存意味著更貴的價格。

（2） 硬碟的轉速。比如民用的SATA硬碟，轉速最多就7200轉/分鐘，而伺服器專用的SAS硬碟，轉速至少都是10000轉/分鐘。

（3） 扇區大小。扇區是磁碟保存數據的最小單位，在Windows中，默認扇區大小為4KB，而在Linux操作系統中，默認扇區大小為8KB，扇區的大小在格式化磁碟的時候指定。扇區的大小意味著存儲數據的最小單位。比如我們設置扇區大小為4K，那麼即使一個1位元組的文件，也會最小消耗4K存儲空間。下圖是筆者的一個只有533個位元組的文本文件，同樣佔用了4K的大小。

扇區設置得越小，越節省磁碟空間，因為每一個扇區的利用率更高。但是性能也會隨之下降，因為如果我們要在磁碟上保存一個100M的文件，對於一個4K扇區大小的磁碟分區來說，就需要25600個扇區來保存。那麼，硬碟在讀取這個文件時，需要向25600個扇區去取內容。而如果我們將扇區調整為64K大小，那麼只需要向1600個扇區取內容，雖然會顯著降低硬碟的讀取速度。但是，這樣的話，一個再小的文件，我們也必須浪費64K空間來存儲。因為一個扇區只對應一個編號，裡面不能存儲兩個文件的內容，這樣硬碟是沒辦法正確讀取到裡面的內容的。

（4） 磁碟碎片：當硬碟使用較久的時候，我們應該進行硬碟的碎片整理，否則硬碟的讀取速度會變慢。這是很多人都知道的常識，但是其原因是什麼呢？通常情況下，硬碟當中的文件如果按照扇區順序保存，機構硬碟的磁頭就可以減少定址的消耗，按順序挨個把內容讀取出來即可。但是，當硬碟使用太久後，由於文件的添加，刪除等操作，導致硬碟需要將一些文件分別保存到一些不連續的扇區中。那麼在讀取文件內容時，磁頭就需要一會兒跑到這個扇區來取一次數據，然後馬上就轉N圈，跑到另外一個扇區去取內容，無疑會增加磁頭的定址時間，降低性能。磁碟碎片整理的原理就在於把分散在各不連續扇區的文件內容移動到挨著的扇區，減少磁頭的定址時間。

另外，對於很多嚴謹的伺服器環境，我們還提供磁碟陣列（RAID），NAS（Network Attached Storage，即網路附屬存儲）等手段來提升硬碟的可靠性和性能。比如我們可以利用RAID 0把一個數據分塊往N塊不同的硬碟上寫，這樣性能便可以提升N倍，當然這樣做的風險就是一旦某塊硬碟損壞，數據無法修復。所以，基於處理速度和可靠性的考慮，還提供了RADI0，1，2，3，4，5，6，7，10，53等各種規範。當然，這些都意味著成本，其實任何性能問題，如果通過花錢就能解決的問題，那麼將不再是問題。無論是CPU，內存，硬碟還是帶寬，都是這個道理。我們做性能測試和性能優化的目的，就是在不增加更多成本的基礎上，盡最大可能壓榨系統的性能。

4. 監控Windows性能指標

Windows操作系統提供了「任務管理器」，可以非常方便地監控到常見的幾個性能指標，如CPU利用率，內存使用情況，網路使用情況，硬碟IO情況，線程數量等。比如在Windows 2003的任務管理器中，我們可以通過在「查看」菜單下的「選擇列」這個操作中把一些要監控的指標納入到監控中：

在新版本的Windows中，還提供了更細緻的監控，比如筆者的Windows 10操作系統中的「資源監視器」，前麵線程的學習中已經講解過。但是無論是「任務管理器」還是「資源監視器」的監控，都存在一個問題，就是它是實時的顯示數據，而無法保存性能數據，當然也無法用於後續的分析，僅僅是用於調試時比較方便而已。但是我們在實施性能測試的過程中，肯定是需要保存這些性能數據的，以供後續的分析。所以此時，我們需要使用Windows自帶的更加全面的「性能監控工具」。具體操作步驟如下：

（1） 運行性能監視器，通常們於Windows的「管理工具」菜單裡面。不同的Windows版本界面和操作上有少許差異，但是整體思路是一致的。筆者的Windows 10的性能監視器啟動後如下圖所示：

（2） 展開「數據收集器集」，選擇「用戶定義」，在右側空白區域點擊「右鍵」->「新建」->「數據收集器集」，打開新建對話框，輸入一個收集器集的名稱，點擊「下一步」並選擇「System Performance「選項並點擊完成，界面如下。

（3） 在左側新建的收集器集上點擊，進入該收集器集的主界面。然後在右鍵的「Performance Counter」條目上右鍵點擊「屬性」，來為該性能計算器設置一些選項。通常的選項設置為：

通常我們建議將日誌格式設置為「逗號分隔」文件（即CSV文件），這樣可以使用Excel直接打開。如果選擇默認的二進位文件，則我們無法直觀地查看監控到的數據。同時，監控時間也建議不要設置為1秒，太頻繁的監控也會消耗計算機資源，並且意義不大。2~5秒的監控周期足夠。

（4） 為收集器集設置持續時間為不限制，這樣我們可以根據需要手工停止。

（5） 選中該數據收集器集，並點擊工具欄上的綠色「啟動」按鈕，開始收集數據。默認設置下，收集到的數據將會保存在「C:PerfLogs」文件夾中。比如此處我們對當前系統監控一段時間，並且運行一下前面實驗中的對Phpwind開發的多線程性能測試腳本（20個線程，每5秒鐘加5個，每個線程運行10次）。當運行完成後，停止監控即可。

（6） 在「C:PerfLogs」目錄下的對應文件夾中，我們可以看到本次監控到的性能測試數據。包括最原始的CSV數據文件，及系統幫我們生成的數據報告。我們可以打開「report.html」查看到一些基本的性能數據分析結果。

（7） 但是上述監控數據內容非常多，由於我們使用的是系統自帶的模板，所以系統會監控很多指標。但是指標太多後其實並不見得是好事，特別是我們對指標還不夠熟悉的時候，「少即是多」，我們應該監控前面提到的幾個重要指標，因為這些指標我們非常理解其作用，這樣才能夠進行有價值的分析。在Windows的「性能監控器」中，我們可以不使用系統自帶模板，而是選擇自定義指標。基本操作如下：

a) 新建一個數據收集器集，命名後選擇「手動創建」，點擊下一步。

b) 在「創建數據日誌」欄勾選「性能計算器」，點擊下一步。

c) 在「性能計數器」中添加我們需要監控的幾個關鍵性能指標即可。如下圖所示：

d) 完成上述設置後，右鍵打開該性能計數器（可能的名稱為「DataCollector01」）的屬性，為該性能計算器設置文件類型為「逗號分隔」文件。

e) 啟動性能測試的時候，啟動該性能計數器開始監控即可。當性能測試執行完成後，手工結束該計數器。

5. 分析Windows性能指標

我們按照自定義的性能計算器對Phpwind的性能測試過程進行全程監控。並設置並發操作策略為：「30個用戶，每10秒鐘添加5個用戶，每個用戶運行20次」。並對最終得到的數據進行分析。當該性能測試執行過程中，現場實時看到的CPU資源利用率如下：

當執行完成後，我們我們利用Excel直接打開該計數器的CSV文件進行，CSV文件的內容如下圖所示：

單純地這樣看會顯得比較費勁，所以現在我們完全可以利用Excel提供的一些功能輔助我們更好地來分析這些性能指標。

（1） 對每一列統計其平均情況，比如統計CPU的平均使用率，平均隊列長度等。

（2） 利用Excel的圖表功能繪製拆線圖，更直觀地查看性能表現。比如我們對CPU使用率這一列繪製拆線圖如下：

通過上述拆線圖我們明顯可以看出CPU隨著並發線程數據增加而增加，減少而減少。並且在30個並發線程的時候，CPU已經達到了100%，出現了瓶頸。當然，此時我們可以繼續查看CPU的隊列長度的監控數據，分析CPU的瓶頸是否嚴重，如果隊列長度比較多，則說明CPU非常忙。如果隊列長度整體看起來還好，那麼CPU還能基本應付得過來，只是用戶會需要多一點等待時間而已。當然，通常一個生產系統中，CPU的使用率一般不應該超過80%。

其它的一些性能指標我們可以利用同樣的方式來完成。此處不再贅述。

6. 監控Linux性能指標

就像Windows的任務管理器一樣，Linux的所有發行版本中也同樣提供了各種監控系統性能指標的命令，比如最典型的「top」命令，此處我們以伺服器端常用的「CentOS」操作系統為例為大家講解。

先來看看Linux中的實時監控命令「top」，類似於Windows中的任務管理器，運行「top」命令後可以監控到的信息如下：

上述命令中的第二行顯示了一共有88個任務，1個正在運行，87個正在休眠。第三行顯示的則是CPU的信息，有0.2%的CPU資源被用戶進程使用（0.2 us），99.7%的CPU資源空閑。第四行顯示了物理內存的使用情況，一共有1.8個多G的物理內存，260多M空閑，500多M被使用，1個多G的內存被用於緩存。第五行顯示是的交換分區（虛擬內存）的使用情況，目前該使用的交換分區沒有被使用。後面的每一行就是每一個進程的具體資源消耗情況。

從上面的數據可以看出，「top」命令監控的數據並不全面。另外一方面，就像Windows一樣，我們在進行性能測試的過程中，不可能只關注這個實時信息，我們需要監控一段時間的數據。所以我們更建議大家使用一個由IBM開發的更加專業的性能指標監控工具「NMon」，下載地址為：「http://nmon. http://sourceforge.net/pmwiki.php」，當我們選擇跟自己的Linux系統匹配的版本後直接下載即可，文件比較小，不到1M。下載完成後將該壓縮包上傳到我們的Linux操作系統中，並按照如下步驟完成操作：

（1） 運行命令「tar –zxvf nmon_xxx.tar.gz」，將壓縮包解壓到當前文件夾中。

（2） 進入解壓後的目錄中，利用命令「chmod 755 nmon_xxx」將該執行文件修改為可執行許可權。Nmon並沒有專門針對CentOS的版本，因為CentOS是與Redhat企業版同源的開源版本，所以我們匹配nmon中的rhel版本即可。

（3） 直接運行命令「./nmon_xxx」即可打開nmon的監控終端，要查看什麼信息直接輸入對應的指令即可，但是這種用法跟「top」一樣，也只能實時查看。

（4） 要將監控數據保存到文件中，我們需要使用另外的命令「./nmon16g_x86_rhel72 -f -s 3 -c 60」即可將監控數據保存到當前目錄下，文件名以.nmon為後綴，以機器名和當前時間為文件名命名。上述命令中「-f」參數表示將監控數據輸出為一個Excel可以處理的文件，「-s 3」表示每3秒鐘監控一次，「-c 60」表示總共採集60次數據。所以整個命令會持續運行3*60=180秒，即3分鐘。

（5） 最後，將採集到的nmon數據傳輸到本地操作系統中即可。

7. 分析Linux性能指標

那麼，我們利用nmon監控到的數據該如何使用呢？其實nmon監控到的數據就是一個CSV文件，我們在Linux中可以直接使用命令「sort xxxxx.nmon」查看到該數據，但是這樣仍然不太方便。所以nmon還為我們開發了一個專用的Excel插件，可以讓我們在Excel更直觀地查看數據。

（1） 先搜索「nmon analyser 下載」，找到任意一個可下載鏈接。

（2） 下載後解壓縮，裡面有兩個文件，一個Word，一個Excel，我們直接打開Excel文件。

（3） 如果Excel彈出安全警告，直接確認啟用即可。啟用該插件後的主界面如圖：

（4） 點擊按鈕「Analyse nmon data」，在打開的對話框中瀏覽到在Linux中監控到的nmon數據文件。

（5） 等待載入數據完成後，我們可以看到在Excel中新增了大量新的Sheet，每一個Sheet對應的就是一個關鍵性能指標，並且自動幫我們生成了分析圖表，讓我們能夠更加直觀地進行指標分析。

通常情況下，除了直接監控整個操作系統的上述關鍵性能指標外。我們還可以基於某個特定的進程進行更詳細的監控。這樣能夠更加容易地獲取到當前伺服器端對應進程的性能情況，便於我們定位問題。不過通常情況下，這不是主要問題，因為在一個伺服器上，通常我們不太會運行過多的其它應用。

思考練習

（1） 請了解關於Apache，IIS，Tomcat，SQLServer, MySQL, Oracle等常用伺服器的關鍵性能指標。

（2） 請自學使用SpotLight性能監控工具。