问题
自今年年初以来，由于我们系统中的 SQL 超时，我们一直在经历严重的用户中断。
有问题的 SQL-Server 实例在工作时间具有非常高的 CPU 使用率（所有 16 个内核上始终高于 90%）。
我们还注意到非常高的等待时间：CXPACKET 和 LATCH_EX 的组合约占所有等待的 97%。这在 CXPACKET 和 LATCH_EX 之间分配了大约 50/50。
占 LATCH_EX 绝大多数 (>95%) 的非缓冲锁存等待是 ACCESS_METHODS_DATASET_PARENT。
这表明问题与并行性有关。
等待时间规模的一个例子是：
CXPACKET : 332,301,799 ms
LATCH_EX : 267,955,752 ms
PAGEIOLATCH_SH : 2,955,160 ms
这是 1 月 11 日 08:00-16:24 之间的时间段。
正在考虑的选项
1) 将 MAXDOP 从 0 更改为 4 到 8 之间的值
2）将并行度的成本阈值从50修改为更高的数字
关于如何缓解我们所看到的非常高的 CPU 负载并减少超时的建议非常受欢迎，特别是建议的行动方案是否明智，以及将 MAXDOP 和并行性的成本阈值更改为哪些数字。
背景资料
SQL-Server 2008 R2 在 AMD Opteron 6180 SE 上运行，其中 16 个内核分配给此 SQL-Server 实例。
工作负载类型：在工作时间内同时连接大约 800 个连接；混合了一些 OLAP 的大多数 OLTP 类型的工作负载。
Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) ... Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1).内存在 24 个内核之间约为 128 Gigs。此实例有 16 个内核可用