none
SQL SERVER 2005在SERVER 2003操作系统下 CPU使用率,进程中sqservr.exe占用内存问题 RRS feed

  • 问题

  • 为什么CPU使用率保持在40%,如何设置,如何提高。同一个数据库需要6小时才能处理完毕(64bit),但在原来工作站(32bit)上1小时就可以处理完毕 我将我现在查询的结果发上来,请大家帮看看如何提升性能!!

    1. 在查询分析器执行“SELECT  SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')”,贴出结果
            9.00.5000.00 SP4 Standard Edition (64-bit)
    2. 在查询分析器执行

    exec sp_configure 'show advanced options', 1
    go
    reconfigure with override
    再执行sp_configure,贴出结果
    Ad Hoc Distributed Queries 0 1 0 0
    affinity I/O mask -2147483648 2147483647 0 0
    affinity mask -2147483648 2147483647 0 0
    affinity64 I/O mask -2147483648 2147483647 0 0
    affinity64 mask -2147483648 2147483647 0 0
    Agent XPs 0 1 1 1
    allow updates 0 1 0 0
    awe enabled 0 1 0 0
    blocked process threshold 0 86400 0 0
    c2 audit mode 0 1 0 0
    clr enabled 0 1 0 0
    cost threshold for parallelism 0 32767 5 5
    cross db ownership chaining 0 1 0 0
    cursor threshold -1 2147483647 -1 -1
    Database Mail XPs 0 1 0 0
    default full-text language 0 2147483647 2052 2052
    default language 0 9999 30 30
    default trace enabled 0 1 1 1
    disallow results from triggers 0 1 0 0
    fill factor (%) 0 100 0 0
    ft crawl bandwidth (max) 0 32767 100 100
    ft crawl bandwidth (min) 0 32767 0 0
    ft notify bandwidth (max) 0 32767 100 100
    ft notify bandwidth (min) 0 32767 0 0
    index create memory (KB) 704 2147483647 0 0
    in-doubt xact resolution 0 2 0 0
    lightweight pooling 0 1 0 0
    locks 5000 2147483647 0 0
    max degree of parallelism 0 64 0 0
    max full-text crawl range 0 256 4 4
    max server memory (MB) 16 2147483647 2147483647 2147483647
    max text repl size (B) 0 2147483647 65536 65536
    max worker threads 128 32767 0 0
    media retention 0 365 0 0
    min memory per query (KB) 512 2147483647 1024 1024
    min server memory (MB) 0 2147483647 0 0
    nested triggers 0 1 1 1
    network packet size (B) 512 32767 4096 4096
    Ole Automation Procedures 0 1 0 0
    open objects 0 2147483647 0 0
    PH timeout (s) 1 3600 60 60
    precompute rank 0 1 0 0
    priority boost 0 1 0 0
    query governor cost limit 0 2147483647 0 0
    query wait (s) -1 2147483647 -1 -1
    recovery interval (min) 0 32767 0 0
    remote access 0 1 1 1
    remote admin connections 0 1 0 0
    remote login timeout (s) 0 2147483647 20 20
    remote proc trans 0 1 0 0
    remote query timeout (s) 0 2147483647 600 600
    Replication XPs 0 1 0 0
    scan for startup procs 0 1 0 0
    server trigger recursion 0 1 1 1
    set working set size 0 1 0 0
    show advanced options 0 1 1 1
    SMO and DMO XPs 0 1 1 1
    SQL Mail XPs 0 1 0 0
    transform noise words 0 1 0 0
    two digit year cutoff 1753 9999 2049 2049
    user connections 0 32767 0 0
    user options 0 32767 0 0
    Web Assistant Procedures 0 1 0 0
    xp_cmdshell 0 1 0 0

     

     

    2011年5月7日 1:50

答案

  • What kind of db process that took 6 hours? How much memory does server have? How did you place db files on the server? Did you reindex/update stats after moving db to new server? Results of sp_configure don't tell much on performance.
    2011年5月7日 3:40
  • 重建索引/重整索引/更新统计看看
    2011年5月9日 3:31
  • 通常来讲,SQL Server的处理瓶颈一般不会在CPU上面,所以CPU用到40%应该是足够的,在内存这块或者查询计划一般问题比较多。这个要具体分析的。建议抓SQL Profiler看看,瓶颈到底在什么地方,哪一步比在x86上慢了。 我看了一下系统设置,是正常的。
    2011年5月10日 16:25

全部回复

  • What kind of db process that took 6 hours? How much memory does server have? How did you place db files on the server? Did you reindex/update stats after moving db to new server? Results of sp_configure don't tell much on performance.
    2011年5月7日 3:40
  • 重建索引/重整索引/更新统计看看
    2011年5月9日 3:31
  • 通常来讲,SQL Server的处理瓶颈一般不会在CPU上面,所以CPU用到40%应该是足够的,在内存这块或者查询计划一般问题比较多。这个要具体分析的。建议抓SQL Profiler看看,瓶颈到底在什么地方,哪一步比在x86上慢了。 我看了一下系统设置,是正常的。
    2011年5月10日 16:25