我已经用Xeon 处理器替换了我的旧处理器。我没有超线程。我的旧处理器具有超线程并且工作正常。
我安装了 SQL Server 2012 标准版。我在服务器上有一个单独的 SQL 服务器实例，具有 92GB 的 RAM。
现在，在更改处理器之后。我在 perfmon 结果中得到了非常高的 CPU 和 100% 的页面错误。
1) 超线程是性能的关键因素吗
2) 是否需要进行任何检查以确保 SQL 服务器已设置为利用来缓解这些页面错误。
3) 是否有任何 DMV 用于等待统计信息，我需要检查 SQL 性能以提供一些关键见解。
4) 是否有我需要评估的 SQL/系统性能计数器的最佳实践。
我遇到的问题是 perfmon 非常占用资源，因此无法在生产服务器上运行它。是否有任何最佳实践来避免这些问题。
5) MAXDOP、处理器关联或 I/O 关联是否值得更改。
我试图根据我的知识和一些谷歌搜索来解释这一点。
1) 超线程是性能的关键因素吗
超线程是“它取决于”的 SQL Server 典型代表。
超线程在您的环境中的行为方式取决于；
Your workload
Windows Server OS version
SQL Server Version
Physical CPU chip/chipset
including cache size
以下是一些关于超线程的广泛指南；
如果导致的逻辑 CPU 计数超过您的操作系统或其他软件支持的 CPU 数量，请关闭超线程。示例：Windows Server 2008 R2 最多支持 64 个逻辑处理器，如果您有 40 个核心服务器（4、10 个核心处理器），超线程将导致 80 个逻辑核心。这比操作系统支持的内核多 16 个。在启动时，这 16 个逻辑核心不会被初始化并且将处于空闲状态。那是 8 个物理核心的处理能力未使用。
关闭 SQL Server 2005 的超线程（在大多数情况下）。一些同步原语看不到超线程的本质，并将其解释为多核处理器，并且可能会发生一些影响性能的软 NUMA 内存行为。当进程执行扫描大块内存时，可能会看到这种情况。它们可能不会影响您的工作量，但可以通过测试来量化您的选择。
使用 SQL Server 2008、2008 R2 和 2012 的工作负载测试超线程。在 SQLOS 中完全支持超线程，没有问题，但您的特定工作负载的性质可能会产生与 I/O 相关的问题或读取效率低下。结果可能会被视为过多的 CXPACKET 等待，这是由于真正的 CPU 线程与超线程 CPU 线程的计时。即使 MAXDOP 设置为 1，也可能观察到高 CXPACKET 等待。
一些困惑：根据 Glenn Berry 的SQL Server Hardware book，“作为一般规则，应该为 OLAP 风格的工作负载禁用超线程，并为 OLTP 风格的工作负载启用超线程，但根据 Simple-talk 主编“Tony Davis”，这是错误的方式，当然，它是以复杂、长时间运行的查询为特征的 OLAP 风格的工作负载，从并行化中受益最大？
好吧，是和否，这取决于您所说的并行化的确切含义。确实，对于 OLAP 工作负载，查询执行性能将受益于允许查询优化器“并行化”单个查询。这是它“分解”查询，将其执行分散到多个 CPU 和线程，然后重新组合结果的过程。对于理想的 OLAP 工作负载，通常将 MAXDOP 设置保留为其默认值零（无界），从而允许优化器将查询执行分散到尽可能多的可用内核上。
不幸的是，事实证明，只有当您拥有大量真正的物理内核（例如一些新的 AMD Magny Cours 处理器提供的）时，这才有效。复杂、长时间运行的查询根本无法在逻辑核心上很好地运行，因此启用 HT 往往会对性能产生不利影响。
msdn 来源：http: //blogs.msdn.com/b/sqladventurer/archive/2012/07/11/hyperthreading-turbo-boost-sql-server-and-you.aspx
和这里的另一个 gud 讨论 https://serverfault.com/questions/194377/will-disabling-hyperthreading-improve-performance-on-our-sql-server-install
2) 是否需要进行任何检查以确保 SQL 服务器已设置为利用来缓解这些页面错误。
要跟踪分页，您可以记录计数器：Memory\ Page Faults/sec、Memory\ Cache Faults/sec 和 Memory\Page Reads/sec。这些跟踪工作集和文件系统缓存中的前两个。页面读取计数器可帮助您跟踪硬页面错误：页面错误率高加上页面读取率高（这些也显示在磁盘计数器中）表明硬错误率很高。
msdn 来源： https ://msdn.microsoft.com/en-us/library/bb742410.aspx https://msdn.microsoft.com/en-us/library/bb742467.aspx
3) 是否有任何 DMV 用于等待统计信息，我需要检查 SQL 性能以提供一些关键见解。
sys.dm_os_wait_stats 动态管理视图 (DMV) 可用于识别系统中的任何主要资源等待。更多细节：https ://www.simple-talk.com/sql/performance/a-performance-troubleshooting-methodology-for-sql-server/
DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR);
4) 是否有我需要评估的 SQL/系统性能计数器的最佳实践。
Memory – Available MBytes
Paging File – % Usage
Physical Disk – Avg. Disk sec/Read
Physical Disk – Avg. Disk sec/Write
Physical Disk – Disk Reads/sec
Physical Disk – Disk Writes/sec
Processor – % Processor Time
SQLServer: Buffer Manager – Page life expectancy
SQLServer: General Statistics – User Connections
SQLServer: Memory Manager – Memory Grants Pending
SQLServer: SQL Statistics – Batch Requests/sec
SQLServer: SQL Statistics – Compilations/sec
SQLServer: SQL Statistics – Recompilations/sec
System – Processor Queue Length
5) MAXDOP、处理器关联或 I/O 关联是否值得更改。是的，
限制和限制
如果关联掩码选项未设置为默认值，它可能会限制对称多处理 (SMP) 系统上 SQL Server 可用的处理器数量。
建议
此选项是一个高级选项，只能由经验丰富的数据库管理员或经过认证的 SQL Server 技术人员进行更改。要使服务器能够确定最大并行度，请将此选项设置为默认值 0。将最大并行度设置为 0 允许 SQL Server 使用最多 64 个处理器的所有可用处理器。要禁止生成并行计划，请将 max degree of parallelism 设置为 1。将该值设置为 1 到 32,767 之间的一个数字，以指定单个查询执行可以使用的最大处理器内核数。如果指定的值大于可用处理器的数量，则使用实际的可用处理器数量。如果计算机只有一个处理器，则忽略最大并行度值。 您可以通过在查询语句中指定 MAXDOP 查询提示来覆盖查询中的最大并行度值。
创建或重建索引或删除聚集索引的索引操作可能是资源密集型的。您可以通过在索引语句中指定 MAXDOP 索引选项来覆盖索引操作的最大并行度值。MAXDOP 值在执行时应用于语句，不存储在索引元数据中。
除了查询和索引操作之外，此选项还控制 DBCC CHECKTABLE、DBCC CHECKDB 和 DBCC CHECKFILEGROUP 的并行性。您可以使用跟踪标志 2528 禁用这些语句的并行执行计划。
msdn 来源：https ://msdn.microsoft.com/en-us/library/ms189094(v=sql.110).aspx