4 個 CPU，共 20 個（NUMA 節點 0），100% 掛鉤
以前的高級 DBA 離開了公司，我了解到一台伺服器存在多個問題，主要是速度緩慢（從 SSMS 需要很長時間才能打開、長時間執行的查詢和 SSIS 作業（數據倉庫）失敗，一直到連接到連結伺服器的困難（其中 150 多個））。
在這個包含 5 個堆疊實例的伺服器上，很可能發生了太多事情。一位新的高級 DBA 將很快加入團隊，但如果在他們加入時為他或她解決這一切，那就太好了。
所以，細節：
當我意識到這個問題時，我發現伺服器記憶體的 94% 都分配給了 SQL Server。我繼續通過從兩個過度配置的實例中釋放記憶體來將其降低到 85%。
然後我注意到我們的預設實例上的 MAXDOP 設置為 4（可能是 6，我不記得了）以及 CPU Affinity 設置。這些 CPU 是固定的，而其他 CPU 的活動很少。我繼續刪除了 Affinity 設置（因為這些設置在添加額外的 CPU 之前就已到位）。我將所有 5 個實例的 MAXDOP 設置為 20。
目前，我仍然看到有 4 個 CPU 固定，但總體平均。使用率（跨所有 CPU）大約只有 25%。
我使用了 SysInternal 的 ProcExp、資源監視器和 Windows 性能工具包來觀察問題，但我真的不知道如何隔離哪些程序，具體來說，是（是）根本原因。關於如何真正隔離這裡發生的事情的任何建議/指導？（即特定的計數器/跟踪/其他程序。）
更新，每個請求：
系統資訊：
Windows Server 2012 R2 Standard
64 GB 記憶體，共
20 個 CPU
配置：
為該實例分配 24 GB 記憶體
為其他實例分配 26.5 GB 記憶體（總計 50.5 GB - 78.9%）
並行成本門檻值 = 50（在所有實例中）
我禁用了一個未使用的 SSAS 程序。
這個問題的原因幾乎可以肯定是在 VM 級別。Ops 團隊將伺服器配置為不僅有 20 個 CPU，還有 20 個插槽。
我在網上讀到虛擬伺服器不區分套接字、核心或 CPU，但是自從我請求更改配置後問題就消失了。此外，VMware 工具沒有報告任何問題。由於未辨識出問題，VMware 故障排除工具甚至不可用（據稱）。
因此，您在單個 Windows 伺服器上有 5 個“堆疊”實例。您還沒有確切地說出有多少個插槽/CPU 可用以及有多少記憶體。在這種情況下，我喜歡為每個實例設置親和力，即使我決定讓 CPU 重疊以平衡整體 CPU 負載（取決於每個實例的負載）。
根據我的經驗，任何具有 4 個以上 CPU 的實例都可以使用顯式 DOP 設置 - 在像你這樣的堆疊情況下很少超過“4”。不要忘記將每個實例的“並行成本門檻值”設置為合理的值（50？）以避免過度並行 - 在您的情況下，這更為重要。
請記住，現在為“作業系統”留下的記憶體應該更多，因為您必須考慮每個實例的佔用空間（在 SSIS 等之上）。如果 SSAS 也在執行，請檢查 SQL Config Mgr 並相應地調整其“最大記憶體”，預設情況下它佔用整個伺服器記憶體的 80% (!)
也可能值得剝奪 SQL 服務帳戶的“鎖定記憶體頁面”權限，以便作業系統可以呼吸並更好地完成工作（如果它分頁，每個人都會受苦！）。另一個好的做法是為每個實例設置一些合理的“最小記憶體”。
我認為在每個實例上執行 sp_blitz 和 sp_blitz_first 會給你一些關於更緊迫問題的快速指示。
您可能還想為每個執行在那裡的程序監視一些 Windows permon 計數器，例如“可用記憶體”和“工作集”，以防您發現伺服器受苦的白天/晚上的特定時間。