上週，我們一個主機代管的客戶，因為客戶端機房搬遷的關係，我們幫客戶的主機關機並且移到另一個機房開機，但開機過後一、兩天，客戶回報主機有效能變差的情況，開啟網站首頁要等好幾分鐘才會出現畫面。當效能降低時，IIS 的反應時間會拉的很長，所以同時上線人數也會開始累積，只要重開 IIS 的應用程式集區就會解決效能問題，但主機的反應還是會頓頓的，我們的人查了好多天還是無法理解其始末，問題也為解決，直到有人提出了一個奇特的症狀 (symptom)，這才讓我找到線索解決這次危機，欲知詳情，請繼續看下去…
我們當天接到客戶通知後，立即協助客戶登入主機查看，結果發現遠端桌面登入後的操作的確不太順暢，使用檔案總管都會頓頓的，感覺伺服器負載非常沈重，於是先查看了 CPU 使用率、記憶體使用率、Disk I/O 等等，大多沒有過載的情況，只是 Disk I/O 忽高忽低的，但平均磁碟佇列長度 (Avg. Disk Queue Length) 並沒有太高，應該不至於有 I/O 瓶頸。
由於客戶的網站是用 PHP 撰寫的，而且每次卡住都是 PHP 程式沒有回應，所以一開始我們就先假設 PHP 程式沒寫好，進而導致效能變差。由於網站上的 PHP 程式並不是我們負責的，我們不會對他們的程式進行任何檢視或修改，所以我們還是先以「系統面」的角度來查問題，對 PHP 網站來說，我會先查看PHP 的錯誤紀錄 (error.log)，結果發現，客戶的 PHP 錯誤紀錄高達 13GB 之多，代表這些年來累積的錯誤如此之多，看到這一點我們立刻將檔案壓縮封存，執行完畢之後，網站速度竟然就變順了。但這一切都是假象，因為其實是因為 IIS 應用程式集區重開的關係才變順的，且 PHP 錯誤紀錄的成長量並不高，不至於造成效能問題才是。所以，我們給客戶的第一個答案是：PHP 程式可能有問題。
不過，客戶的回應是：「在主機搬遷前後並沒有人動過程式喔，而且網站已經跑了 3, 4 年，都沒有目前這麼慢過，是你們搬遷主機之後才變慢的。」
ㄜ…. 遭了！拿了石頭砸到了自己的腳 XD
客戶說的有道理，如果按照邏輯來看，的確是這樣說沒錯，因此我們開始往其他角度思考問題。我接著思考，效能出問題，最重要的就是要有數據，感覺不能當飯吃，這是我一直給自己的要求。但我們透過效能監視器得到的數據並沒有發現值得一提的數字 (其實是沒有找到正確的計數器出來看)，所以一直沒辦法找到效能瓶頸的那個點。
我同事查了一段時間，他告訴我他發現到的一個現象，就是每次開檔案總管時，進入每一個目錄都會感覺有點延遲(lag)，有時候會有點慢，有時候則是非常慢。我前去查看後，發現的確如此，這個線索對我來說非常有幫助，因此，我試圖進入 PHP 錯誤紀錄的資料夾，也就是 C:\Windows\Temp 系統暫存目錄，當我透過快速鍵按下 Win + E 並用鍵盤進入 C:\Windows\Temp 系統暫存目錄時，我同事跟我說「且慢」，但來不及，我手太快，已經按下 Enter 鍵進入該目錄了！ XD
同事跟我說，進入 C:\Windows\Temp 系統暫存目錄的話，檔案總管會當掉，即便用命令提示字元進入該目錄，就算打個 dir 指令，也要等一個半小時才會有回應。
ㄜ….這訊息對我太重要啦！
最後，我用以下指令匯出該目錄下的檔案清單，結果發現光是一個 C:\Windows\Temp 目錄裡，就有超過兩百萬個檔案：
cd /d c:\windows\temp
dir /a > c:\temp_files.txt
接著查一下，這個系統暫存目錄下到底都放了哪些檔案在裡面？為什麼可以有這麼多檔案？最後才發現，有一百多萬個 sess_* 開頭的檔案，而這個是 PHP 的 Session 檔案，累積了多年，從來沒刪除過，所以才會這麼有這麼多。
不過，若要直接刪除這些暫存檔，現有登入的會員會立即登出（因為 Session 消失），所以我們必須採取較為緩和的作法，透過程式刪除那些太舊的檔案。還好 Windows Server 2003 開始，就有了 Forfiles 工具程式，可以方便我透過一行指令來刪除這些檔案。因此我寫了一個批次檔，用來刪除 7 天以前所有 sess_* 開頭的檔案，其指令如下：
forfiles /P c:\Windows\Temp /M sess_* /S /D -7 /C "cmd /c del /F @path"
一行指令，執行了約 20 個小時，才把所有檔案刪除完畢，刪除完後，網站的執行速度比搬遷前還快好幾倍，問題解決！ ^__^
關於這次的效能狀況，推薦三個計數器，供各位參考：
相關連結