之前的高级 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 Performance Toolkit 来观察这个问题，但我真的不知道如何隔离哪些进程，具体来说，是根本原因。关于如何真正隔离这里发生的事情的任何建议/指导？（即特定计数器/跟踪/其他程序。）
更新，根据请求：
系统信息：
Windows Server 2012 R2 Standard
64 GB 内存共
20 个 CPU
配置：
分配给此实例的 24 GB 内存
分配给其他实例的 26.5 GB 内存（总计 50.5 GB - 78.9%）
并行度的成本阈值 = 50（跨所有实例）
我禁用了一个未使用的 SSAS 进程。
因此，您在单个 Windows 服务器上有 5 个“堆叠”实例。您还没有确切说明有多少套接字/CPU 可用以及有多少内存。在这种情况下，我喜欢为每个实例设置亲和力，即使我决定让 CPU 重叠以平衡整体 CPU 负载（取决于每个实例的负载）。
根据我的经验，任何具有 4 个以上 CPU 的实例都可以使用显式 DOP 设置——在像您这样的堆叠情况下很少超过“4”。不要忘记将每个实例的“并行成本阈值”设置为合理的值（50？）以避免过度并行 - 在您的情况下，这更为重要。
请记住，“为操作系统”留下的内存现在应该更多，因为您必须考虑每个实例的占用空间（在 SSIS 等之上）。如果 SSAS 也在运行，请检查 SQL Config Mgr，并相应地调整其“最大内存”，默认情况下它会占用整个服务器内存的 80%（！）
也可能值得取消 SQL 服务帐户的“在内存中锁定页面”权限，以便操作系统可以呼吸并更好地完成其工作（如果它页面，每个人都会受苦！）。同样好的做法是为每个实例设置一些合理的“最小内存”。
我认为在每个实例上运行 sp_blitz 和 sp_blitz_first 会给你一些关于更紧迫问题的快速指示。
您可能还想监视一些 Windows permon 计数器，例如在那里运行的每个进程的“可用内存”和“工作集”，以防您发现服务器出现问题的白天/晚上的特定时间。
这个问题的原因几乎可以肯定是在 VM 级别。Ops 团队将服务器配置为不仅有 20 个 CPU，还有 20 个插槽。
我在网上读到虚拟服务器不区分套接字或内核或 CPU，但自从我请求更改配置后问题就消失了。此外，VMware 工具没有报告任何问题。VMware 故障排除工具甚至不可用（据称），因为没有识别出问题。