在 Windows Server 2008 上浪費了多少時間？
我正在使用在 Hyper-V VM 中執行的 Windows Server 2008。系統性能很差。我們很確定這是由於記憶體不足。我查看瞭如何確定我的 Windows Server 2003 是否需要更多記憶體？，而且我很確定看到每秒輸入 > 300 頁，記憶體就是問題所在。
但是，我要問一個更廣泛的問題。我想將管理層的注意力集中在等待這些頁面錯誤時所浪費的時間上。有沒有辦法確定等待分頁或其他資源所花費的時間？我對互動式使用者花費的時間特別感興趣，但包含非互動式使用的數字也會有所幫助。
澄清一下，所以這似乎不像抱怨：
這個系統太慢了，當一個notepad.exe視窗處於活動狀態時，它需要幾分鐘才能啟動已經打開並顯示的第二個notepad.exe視窗。那隻是啟動。表現也不算差。我認為這相當於每天浪費了數十個工時。
我正在尋找一種方法向管理層說明浪費了多少時間。這發生在我們實際上沒有十個工時可以浪費的時候。
抱歉，我沒有提供更多細節。
此伺服器正用於 SharePoint (WSS 3.0) 開發。它執行 IIS 7，每個開發人員至少有一個應用程序池。每個開發人員都有一個或多個 Web 應用程序，每個應用程序都設置在分配給該開發人員憑據的 AppPool 中。我們正在執行 Visual Studio 2008 SP1 和 SQL Server 2008。SQL Server 數據位於與作業系統不同的虛擬磁碟上。
我一次在系統上看到了多達 8 個開發人員。伺服器配置了 2GB 的 RAM，由於主機的限制，此時更多的 RAM 並非易事。如果我能提出足夠的理由來糾正它，我希望這將得到糾正，形式是：這是浪費了多少時間。
編輯
感謝您的回答和評論。我同意該解決方案 - 將 SharePoint 負載載入到 4-8GB 的伺服器上，並將 SQL Server 移動到第二個 2-4GB 的伺服器上。
但我的問題更像是：是否有任何性能計數器或工具可以告訴我等待頁面讀取和寫入所花費的*時間？*有什麼可以告訴我等待排隊磁碟 I/O 所花費的時間嗎？
可以獲得諸如“每秒輸入的頁面數”之類的性能計數器，但很難說該計數器的值是“太多”。如果有“計數器”可以說明由於每秒輸入的頁面而花費了多少時間，這對我的目的會更好。
此伺服器正用於 SharePoint (WSS 3.0) 開發。它執行 IIS 7，每個開發人員至少有一個應用程序池。每個開發人員都有一個或多個 Web 應用程序，每個應用程序都設置在分配給該開發人員憑據的 AppPool 中。我們正在執行 Visual Studio 2008 SP1 和 SQL Server 2008。SQL Server 數據位於與作業系統不同的虛擬磁碟上。
我一次在系統上看到了多達 8 個開發人員。伺服器配置了 2GB 的 RAM，由於主機的限制，此時更多的 RAM 並非易事。如果我能提出足夠的理由來糾正它，我希望這將得到糾正，形式是：這是浪費了多少時間。
甚至無需考慮 SharePoint 2007 的硬體要求，最多可以有 8 個開發人員擁有自己的應用程序池。我假設SQL Server 是另一台 VM，但如果它是同一台 Win2k8 機器，則毫無疑問是什麼問題。
用於 VisualStudio 開發的 AppPools（2005-2008 版本）可以很容易地增長到每個 AppPool 150MB-250MB，這取決於許多因素。250mb x 8devs = 2gb 使用。讓我們不要忘記作業系統本身需要的記憶體，可能還有 SQL Server。簡而言之：您根本沒有足夠的 RAM。盡可能多地載入到 RAM 上。如果它至少從後台的角度和可能的前景解決了伺服器的大部分“緩慢”，我不會感到驚訝。
僅供參考：Microsoft 建議 SharePoint 2007 應用程序伺服器（連結）至少 4GB，但實際上，Microsoft 盡可能多地佔用資源。現在在同一個 URL 中，他們提到了獨立 SharePoint 伺服器的最低 2GB，但如果開發人員直接使用他們**自己的 AppPool在該伺服器上工作，很明顯 IIS 正在耗盡 AppPools/Sites 的所有可用記憶體。不要使用推薦的最低 RAM。如果可能，請嘗試將 RAM 需求增加一倍、三倍、四倍（預算允許）。
**編輯：**您提到 SQL Server數據位於單獨的虛擬磁碟上，但 SQL Server 是否安裝在同一 SharePoint 伺服器上？SharePoint 伺服器上還有多少可用儲存空間？這些附加因素很容易消耗伺服器資源，不容忽視。
**再次編輯：**由於您提到（我沒有閱讀）“由於主機的限制，此時 RAM 並非微不足道”，因此只有一個真正的解決方案：獲得一台新的主機。2GB 不足以執行 SharePoint/SQL/IIS/任何時期。抱歉，恕我直言，執行它的機器至少應該有 8GB RAM。
OP編輯後編輯：
但我的問題更像是：是否有任何性能計數器或工具可以告訴我等待頁面讀取和寫入所花費的時間？有什麼可以告訴我等待排隊磁碟 I/O 所花費的時間嗎？
我沒有遇到您的確切情況，但是 Microsoft TechNet 上有一篇關於監控指標基礎的好文章（連結）。我不確定花在等待排隊磁碟 I/O 上的時間是否是獲得你想要的東西的最佳方式（我假設管理支持）。
可以獲得諸如“每秒輸入的頁面數”之類的性能計數器，但很難說該計數器的值是“太多”。如果有“計數器”可以說明由於每秒輸入的頁面而花費了多少時間，這對我的目的會更好。
Server 2003 上來自 Windows Networking (連結)的一篇文章比我能更好地解釋這些計數器。自由貿易協定：
Memory\Pages/sec計數器指示在測量間隔期間對磁碟的分頁操作數，這是主要的計數器，用於監視 RAM 可能不足以滿足伺服器需求的指示。這裡的一個好主意是配置一個 perfmon 警報，當系統上每個頁面磁碟的每秒頁面數超過 50 時觸發該警報。此處要注意的另一個關鍵計數器是 Memory\Available Bytes，如果此計數器大於您機器中實際 RAM 的 10%，那麼您可能擁有足夠多的 RAM，無需擔心。
您應該對Memory\Available Bytes計數器做兩件事 ：為該計數器創建性能日誌並定期監視它以查看是否有任何下降趨勢，並設置警報以在低於已安裝 RAM 的 2% 時觸發。如果確實出現下降趨勢，您可以監控 每個程序實例的Process(instance)\Working Set，以確定哪個程序正在消耗越來越多的 RAM。 Process(instance)\Working Set測量每個程序的工作集的大小，這表明程序可以在不產生頁面錯誤的情況下處理已分配的頁面數。一個相關的計數器是 Memory\Cache Bytes，它測量系統的工作集，即核心執行緒可以在不產生頁面錯誤的情況下處理的已分配頁面的數量。
最後，RAM 不足的另一個確證指標是 Memory\Transition Faults/sec，它衡量備用列表上最近修剪的頁面被重新引用的頻率。如果這個計數器隨著時間的推移慢慢開始上升，那麼它也可能表明你已經達到了一個點，你不再有足夠的 RAM 來讓你的伺服器正常執行。
所以我想說這個解釋真正解決了您的指標以及對指標對您的實際意義的理解。性能監視器有點棘手，特別是如果您不完全了解計數器在總體方案中的含義。我通常會發現自己閱讀有關計數器的內容，因為很容易忘記它們的“真實世界”含義。