SQL性能

Question

我用Xeon处理器替换了我的旧处理器。我没有超快的线程。我的旧处理器有超线程，工作正常。

我已经安装了SQL server 2012标准版本。服务器上只有一个SQL server实例，内存为92 of。

现在，在对处理器进行更改之后，.I在perfmon结果中得到了一个非常高的CPU和页面错误，这是100%的错误。

1)超线程是否是性能的关键因素？

2)是否需要检查是否设置了SQL服务器以利用这些页面错误。

3)是否有任何用于等待统计的DMV，我需要检查SQL性能，这将提供一些关键的洞察力。

4)我是否需要评估SQL/系统性能计数器的最佳实践。

我遇到的问题是perfmon非常耗费资源，因此无法在生产服务器上运行它。是否有最佳做法来避免这些问题。

( 5) MAXDOP、处理器亲和力或I/O亲和力是否值得改变。

Answer 1

我试着按照我的知识和一些谷歌来解释这一点。

1)超线程是性能的关键因素吗？

超线程是"it依赖“的Server海报子程序。

超线程在您的环境中的表现取决于；

Your workload
Windows Server OS version
SQL Server Version
Physical CPU chip/chipset 
including cache size 

以下是一些关于超线程的广泛指南；

如果将导致的逻辑CPU计数超过操作系统或其他软件支持的CPU数量，则关闭超线程。示例: Windows 2008 R2支持多达64个逻辑处理器，如果您有40个核心服务器(4个，10个核心处理器)，超线程将导致80个逻辑核。这是超过操作系统将支持的16个核心。在启动时，这16个逻辑核将不会被初始化，并且将处于空闲状态。这是8个物理核心的处理能力没有使用。

关闭Server 2005的超线程(在大多数情况下)。一些同步原语没有看到超线程是什么，并将其解释为一个多核处理器，并且可能会出现一些影响性能的软NUMA内存行为。当进程通过大内存部分执行该扫描时，可能会看到这一点。它们可能不会影响您的工作量，尽管如此，用测试来量化您的选择。

使用Server 2008、2008 R2和2012年的工作负载测试超线程。超线程在SQLOS中是完全支持的，没有问题，但是特定工作负载的性质可能会产生与I/O相关的问题或读取的效率。结果可能被看作是过多的CXPACKET等待，这是由于真正的CPU线程vs.hyperthreading CPU线程的定时所致。即使将MAXDOP设置为1，也可以观察到较高的CXPACKET等待。

一些困惑:根据格伦·贝瑞的SQL服务器硬件手册，“作为一种一般规则，超线程应该禁用OLAP样式的工作负载，而启用OLTP风格的工作负载，但是按照"Tony”的简单对话编辑器，这是不对的。，当然，它是OLAP风格的工作负载，其特点是复杂的、长时间运行的查询，这将最大地受益于并行化？

嗯，是和不是，这完全取决于你所说的并行化是什么意思。当然，对于OLAP工作负载，允许查询优化器“并行”单个查询将有利于查询执行性能。这是一个过程，它“分解”一个查询，将其执行扩展到多个CPU和线程，然后重新组合结果。对于理想的OLAP工作负载，通常将MAXDOP设置保留为0(无界)，允许优化器将查询执行扩展到可用的多个核心。

不幸的是，只有当你有大量真实的物理内核(比如由一些新的AMD Magny Cours处理器提供的)时，这才能很好地工作。复杂的、长期运行的查询在逻辑核上不能很好地运行，因此启用HT往往会对性能产生不利影响。

资料来源：http://blogs.msdn.com/b/sqladventurer/archive/2012/07/11/hyperthreading-turbo-boost-sql-server-and-you.aspx

还有另外一个关于https://serverfault.com/questions/194377/will-disabling-hyperthreading-improve-performance-on-our-sql-server-install的gud讨论

( 2)是否有任何检查需要确保将SQL server设置为利用这些页面错误。

要跟踪分页，可以记录计数器:内存\页错误/秒、内存\缓存故障/秒和内存\页读取/秒。前两个跟踪工作集和文件系统缓存。帮助您跟踪硬页错误:页面错误率高和页面读取率高(这些错误也显示在磁盘计数器中)表明硬错误率很高。

资料来源：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'，清除)；

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亲和力是否值得改变。是,

限制和限制

如果关联掩码选项未设置为默认值，则可能会限制Server在对称多处理(SMP)系统上可用的处理器数量。

建议

此选项是高级选项，仅应由经验丰富的数据库管理员或经过认证的SQL Server技术人员进行更改。若要使服务器能够确定最大并行度，请将此选项设置为默认值0。将最大并行度设置为0允许Server最多使用64个可用处理器。若要抑制并行计划生成，请将最大并行度设置为1。将值设置为从1到32,767，以指定单个查询执行可使用的最大处理器核数。如果指定的值大于可用处理器的数量，则使用可用处理器的实际数量。如果计算机只有一个处理器，则忽略最大并行度值。可以通过在查询语句中指定MAXDOP查询提示来覆盖查询中的最大并行度值。

创建或重新生成索引或删除聚集索引的索引操作可以是资源密集型操作。通过在index语句中指定MAXDOP索引选项，可以重写索引操作的最大并行度值。MAXDOP值在执行时应用于语句，而不是存储在索引元数据中。

除了查询和索引操作之外，此选项还控制DBCC、DBCC和的并行性。可以使用跟踪标志2528禁用这些语句的并行执行计划。

资料来源：https://msdn.microsoft.com/en-us/library/ms189094(v=sql.110).aspx