主页 / dba / 问题 / 188284
Accepted
Web Dev Guy
Asked: 2017-10-12 20:50:55 +0800 CST

SQL Server CPU 使用率有时会超载

  • 772

我们确实有几台服务器，一台专用于没有 SQL 的网站，另一台专用于 SQL。

现在运行 SQL 的服务器非常强大，但有时服务器 CPU 只是在 100% 时达到最大值。

这是几个屏幕截图，显示了正在发生的事情。

CPU 已满：

在此处输入图像描述

CPU 运行正常：

在此处输入图像描述

如您所见，服务器非常强大。

补充说明。

  1. 我们正在运行 nopcommerce 3.70 版
  2. 该网站已被其他开发人员大量定制。
  3. 该网站有大约 4000 - 5000 种产品。
  4. 当 cpu 最大化时，加载时间令人震惊。> 30 秒，有时超过 1 分钟。

有没有人能够阐明可能发生的事情，或者指导我检查一些事情。

干杯

更新：以下两个屏幕截图是@S4V1N 建议我运行的两个查询的结果。

在此处输入图像描述

在此处输入图像描述

sql-server windows-server

3 个回答

  1. Best Answer

    有没有人能够阐明可能发生的事情，或者指导我检查一些事情。

    让我们从显而易见的东西开始。您的服务器，用于生产 SQL 框，并没有那么强大。例如，这就是我做的开发工作，而我大部分时间只是一个闲逛的顾问。

    坚果

    话虽如此，更多的硬件可能无法解决您的所有问题。我不熟悉您提到的平台，但通常当您从基础产品开始时，您开始将其称为“高度定制”，这意味着过去与基础产品一起使用的代码和索引可能不不再那么好用了。

    你可以从什么开始？

    我工作的公司编写免费脚本，可以帮助您了解这些事情的根源。无论是您可以通过硬件修复，还是通过供应商支持修复，都是另一回事。

    许多供应商不喜欢您对他们的产品进行更改。但是，嘿，至少你可以开始讨论做出改变。

    1. 运行 sp_Blitz

    EXEC sp_Blitz @CheckUserDatabaseObjects = 1, @CheckServerInfo = 1;

    这将使您大致了解服务器的健康状况。请注意此处的几个设置：MAXDOP 和并行性成本阈值，并在此处查看我的答案，了解它们为什么可以改变您的情况。

    1. 运行 sp_BlitzFirst

    EXEC sp_BlitzFirst @SinceStartup = 1;

    这将告诉您您的服务器自启动以来一直在做什么。查看等待统计信息窗格，了解您的瓶颈在哪里。

    坚果

    1. 运行 sp_BlitzCache

    EXEC sp_BlitzCache @SortOrder = 'cpu';

    坚果

    由于您关心您的计划缓存，请先按CPU查看。您可能会发现其他排序顺序很有帮助，但从这里开始。

    我们会警告您查询计划中的各种内容，并为您提供尽可能多的历史信息。

    1. 运行 sp_BlitzIndex

    EXEC sp_BlitzIndex @DatabaseName = N'YourDatabaseName', @Mode = 4

    您在这里要查看的主要内容是高价值缺失索引，它应该就在顶部。

    1. 当你捕捉到 CPU 峰值时，运行 sp_BlitzWho

    EXEC sp_BlitzWho

    这会让您知道当 CPU 较高时正在运行哪些查询。它们可能与计划缓存中的不同。

    希望这可以帮助！

    • 6

  2. 使用任务管理器监控 CPU 使用情况并不是真正可靠的来源。还有许多其他（例如核心操作系统活动、设备驱动程序）在后台运行的非 sql 进程可能会在您不知道的情况下增加额外的开销。

    在这些情况下，PerfMon 是您应该使用的工具。

    Processor/%Privileged Time, Processor/%User Time, Process (sqlservr.exe)/%Processor Time

    将让您了解 SQL Server 实际发生的情况，无需解释每个计数器，打开描述复选框并从那里读取，但它本质上会显示 SQL Server 与其他进程使用率的比率。

    尽管它很容易发现，但它并不容易诊断。可能还有其他“隐藏”问题表明处理器是问题所在。例如有很多编译/重新编译，这是与非参数化查询或强制重新编译相关的问题。您可以在 Perfmon 中找到这些指标：SQLServer:SQL Statistics/SQL Compilations/sec、SQLServer:SQL Statistics/SQL Re-Compilations/sec。

    SQLServer:Plan Cache/Cache hit Ratio表示内存问题，但是过多的页面刷新进/出内存也会增加额外的 CPU 使用率。

    DMV 还可以帮助您诊断问题。

    SELECT TOP ( 10 )
wait_type ,
waiting_tasks_count ,
( wait_time_ms - signal_wait_time_ms ) AS resource_wait_time ,
max_wait_time_ms ,
CASE waiting_tasks_count
WHEN 0 THEN 0
ELSE wait_time_ms / waiting_tasks_count
END AS avg_wait_time
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE '%SLEEP%' 
AND wait_type NOT LIKE 'XE%'
AND wait_type NOT IN
( 'KSOURCE_WAKEUP', 'BROKER_TASK_STOP', 'FT_IFTS_SCHEDULER_IDLE_WAIT',
'SQLTRACE_BUFFER_FLUSH', 'CLR_AUTO_EVENT', 'BROKER_EVENTHANDLER',
'BAD_PAGE_PROCESS', 'BROKER_TRANSMITTER', 'CHECKPOINT_QUEUE',
'DBMIRROR_EVENTS_QUEUE', 'SQLTRACE_BUFFER_FLUSH', 'CLR_MANUAL_EVENT',
'ONDEMAND_TASK_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH', 'LOGMGR_QUEUE',
'BROKER_RECEIVE_WAITFOR', 'PREEMPTIVE_OS_GETPROCADDRESS',
'PREEMPTIVE_OS_AUTHENTICATIONOPS', 'BROKER_TO_FLUSH' )
ORDER BY wait_time_ms DESC

    看看你是否能找到 SOS_SCHEDULER_YIELD & CXPACKET 等待。如果 SOS_SCHEDULER_YIELD 等待时间很高，您可能会遇到一些 CPU 非常广泛的查询，您应该注意这些查询。这个：

    SELECT TOP ( 10 )
SUBSTRING(ST.text, ( QS.statement_start_offset / 2 ) + 1,
( ( CASE statement_end_offset
WHEN -1 THEN DATALENGTH(st.text)
ELSE QS.statement_end_offset
END - QS.statement_start_offset ) / 2 ) + 1)
AS statement_text ,
total_worker_time / 1000 AS total_worker_time_ms ,
( total_worker_time / 1000 ) / execution_count
AS avg_worker_time_ms ,
total_logical_reads ,
total_logical_reads / execution_count AS avg_logical_reads ,
total_elapsed_time / 1000 AS total_elapsed_time_ms ,
( total_elapsed_time / 1000 ) / execution_count
AS avg_elapsed_time_ms ,
qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
ORDER BY total_worker_time DESC

    将向您展示您可能希望进一步优化的最广泛的 CPU 查询。

    优化这些查询，您可能会发现缺少索引、过时的统计信息、非 sarg-able 查询，这些都是高 CPU 使用率背后的实际问题。

    它不是解决 CPU 问题的唯一蓝图，但我希望它能给你一个好的开始！

    • 2

  3. 有两件事可能发生。

    让我们从以下内容开始：在 SQL Server 的大多数用例中，CPU 是负担最少的元素。它只是不会超载。时期。有一些例外，但在我想说的情况下，99% 的 CPU 过载可以追溯到糟糕的 SQL 或表设计，这使得 SQL Server 浪费了大量的 CPU 周期——进行实际上是不必要的数据转换。

    示例：表 1 的 ID 字段是整数，表 2 引用它但外键是字符（存储数值）。欢迎在每次加入时进行数据转换 - 完全可以避免，通常是一个很容易修复的“愚蠢”错误（被忽略的数据类型或其他东西）。几乎一样糟糕的是使用 NVarchar（在 SQL Server 中）字符字段进行查找 - Unicode 字符串比较规则很复杂，N（例如对于产品代码表）很容易是纯 VARCHAR 的 20 倍 CPU 密集型（确实不处理 Unicode）。有时你需要它，但有时它只是愚蠢的规定（所有字段都是 Unicode，即使是那些包含电话号码之类的东西）。

    要解决此问题，您确实需要进入慢查询并识别它们 - 周围有很多工具，即使在 SQL Server Management Studio 中也是如此。活动监视器（文档可以帮助您找到它）很乐意为您提供 CPU 最近最昂贵的查询 - 然后您可以查看它们并开始找出错误所在。我敢肯定，一项体面的调查将指向许多易于修复的问题，这些问题非常微不足道，但会导致所提到的极端 CPU 使用率。

    但是作为元素 - 你说得很好：“现在运行 SQL 的服务器非常强大” - 我不想在这里违背你的幻想，但这是 2017 年。具有 14gb 内存的 4 核机器并不是“非常强大” . 它本质上是“低端”。我不会在这样的桌面上工作。现在，我不是说“买一台更大的机器”，只是不要把超低端规格吹嘘为高端，拜托。市场上有比你的“相当强大”的服务器更强大的平板电脑。请注意，虽然服务器可用性问题（内存不足，IO 带宽不足）通常会导致 CPU 不足（CPU 等待），因此这与此特定问题无关。一旦遇到麻烦，您可能只考虑服务器扩展。为了让您了解您的机器有多低端 - 您运行 SQL Server，这需要许可的 Windows。您可以购买的最小 Windows Server 许可证涵盖 16 个内核，是您数量的 4 倍。

    • 1

相关问题