none
视图查询CPU时间特别长 RRS feed

  • 问题

  • 数据库版本2014 ,打了最新补丁。做的是 无域控的 ALWAYSON 

    select * from v_tt   where name like '什么东东' or name = '什么东东'

    这个视图非常复杂,里面十几个表JOIN 。在主节点 4CPU 96 核  执行时间17s ,在从节点  4CPU 48 核执行 1s 

    执行计划

    开始怀疑是执行计划的问题。但是把从节点的执行计划复制到主节点,使用USE PLAN指定一样的执行计划,速度还是一样。

    等待

    执行时,没有等待

    由上图可以知道,逻辑读不算高,但是CPU 使用时间特别高.

    SQL Server 分析和编译时间: 
       CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。
    SQL Server 分析和编译时间: 
       CPU 时间 = 265 毫秒,占用时间 = 277 毫秒。

    (1 行受影响)

     SQL Server 执行时间:
       CPU 时间 = 15484 毫秒,占用时间 = 16954 毫秒。
    SQL Server 分析和编译时间: 
       CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。

     SQL Server 执行时间:
       CPU 时间 = 0 毫秒,占用时间 = 0 毫秒。

    总共4个NUMA节点,我看了下CPU使用还是比较平均。不确定是不是有关系。 .修改了电源选项 平衡改到高性能。 没有什么效果.怀疑是CPU 本身的问题,但是有没有验证的办法, CPU 型号:e7 8850 v2  比从节点的CPU更好才对。希望大家给提供下其他的思路,非常感谢

    2017年12月7日 2:06

全部回复

  • 自己顶一下,,,
    2017年12月7日 5:19
  • always on 主备切换一下,看看切换后的表现是怎么样的
    2017年12月7日 6:10
  • 客户的在线系统,不是很好直接测试。跟AWO有什么关联吗
    2017年12月7日 6:15
  • Hi owen_zeng,

    我之前倒是遇到过Always-on影响主节点的性能的case,你跑一下下面的query(两个节点都跑一下):

    select cpu_id,context_switches_count,idle_switches_count,current_tasks_count,current_workers_count,load_factor,total_cpu_usage_ms,total_scheduler_delay_ms,total_cpu_idle_capped_ms from sys.dm_os_schedulers

    还有,这个E7的CPU有没有开启超线程啊?

    Best Regards,

    Teige


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    2017年12月7日 6:28
    版主
  • 有打开超线程。
    2017年12月7日 7:30
  • 怀疑是CPU 本身的问题,但是有没有验证的办法”,你可以把超线程关闭试一下,之前遇到过好几个案例就是超线程会导致查询速度变慢。


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    2017年12月7日 7:36
    版主
  • 我也有怀疑过,不过次节点也是有超线程的。
    2017年12月7日 7:40
  • 上面这个查询你主要想看哪个栏位,后面的3个栏位在2014 是没有的
    2017年12月7日 7:40
  • 主副本

    次副本

    2017年12月7日 7:43
  • 我也有怀疑过,不过次节点也是有超线程的。
    Did you see any wait when execute that query?
    2017年12月7日 14:11
  • 不用想太多可能

    如果可以修改代码,拆开每次JOIN四五个表是最简单的处理方式

    之前解决过一个案例是JOIN十几个表要40+s,拆开后2s

    或者加个提示限制并行度试下


    SQL Server 2016 ~ 2000 性能优化、方案设计 QQ:315054403 田园嘉兴

    2017年12月7日 23:38
  • 看过了,查询时没有等待信息

    2017年12月11日 1:23
  • 这个语句本就没有使用并行。拆分这个办法是想过,现在问题是这个视图是客户的,不好随便改动。其次想看看原因是是什么,,
    2017年12月11日 1:24
  • option(maxdop 1)试试看,或者看看sysprocesses表中是否存在同一个spid多条记录的情况,如果存在,那说明应该是并行度引起的
    2017年12月14日 2:01
  • 语句的执行计划本来就没有走并行,因为开销没有超过并行阈值。
    2017年12月14日 2:07