none
sql server 2k8 cluster遇到的性能问题 RRS feed

  • 问题

  • 背景资料: 

    SQL SERVER 2K8 做了群集,稳定运行1年有余,近一个月内,出现查询异常;与Sql进行连接的是额外的一台WEB服务器。 

    问题描述:

    1、 A地:两台服务器无论活动节点在哪个服务器上,在执行SQL查询时,均表现很慢,这两台服务器均为本地服务器,通常需要40秒左右才能得出结果(数据量约170万),而相同的程序代码,在另外一个外地(B地)的服务器上,同样的查询,只需要2秒,外地的服务器无群集,SQL 2K8(独立) +IIS WEB(独立),数据量略少于170万,但数量级相当;

    2、 基础硬件层面上,确认不是硬件的问题,I/O也没有问题,我们的开发人员看代码也找不到根本原因在哪里。

    尝试的解决方法:

    1、 调整内存分配,由原来的16G调整24G,然后又调整到8G,再调整到12G,此后,重新执行SQL查询;所用时间变为大约7秒;将相同的SQL还原至其他单独的服务器中,同样的业务压力下,所用查询2秒;

    2、 A地群集工作时,停止前端的WEB服务器后,重新进行查询,时间变回2秒,即没有业务发生时,查询时间为2秒。

     

    目前,我们不知道问题到底出在哪里,我们基本上没有做过多的操作,只是调整了一下内存,停止IIS测试了一下而已,服务器的SQL基本恢复了原有状态,我们不清楚什么原因,在发生问题时以及系统基本恢复后,我们进行了SQL Profiler的分析,并留有截图,希望有人能指导一下,这到底是哪里出了问题,未来我们该如何避免类似问题的发生;如果需要提供进一步资料,我会随时进行补充。

    2011年10月21日 3:37

全部回复

  • 系统恢复之前执行SQL Profiler抓图

    2011年10月21日 3:41
  • 系统恢复之后执行SQL Profiler抓图

    2011年10月21日 3:42
  • 磁盘I/O看起来很大,检查一下硬盘读写,整理一下硬盘碎片,重建一下数据库索引都是可以尝试的办法。

    2011年10月21日 3:52
  • 那个恢复之前的读也太大了吧.千万级别....
    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.
    2011年10月21日 5:15
  • 那个恢复之前的读也太大了吧.千万级别....
    If you haven't all the things you want,be grateful for the things you don't have that you didn't want.

    索引重构过。  碎片大于30,重建索引 ,碎片小于30,重新组织索引   ,那个读取还是在索引重构之后查询的。
    • 已编辑 yyppcc 2011年10月21日 5:38
    2011年10月21日 5:37
  • 需要做一些测试,才能确定问题所在。

    1. 是否IIS频繁发起加锁之类的查询

    例如在系统恢复之后,你再重新打开IIS前端和禁用IIS,发起同样的查询,对比一下。可以用ssms的activity monitor看一下当前有哪些进程在活动着以及在执行什么样的任务。

    2. 是否因为内存不足

    你做了内存调整之后,内存中的缓存页会被强制清空,因此这个时候测试和之前测试有可能会得到不一样的结果。

    3. 是否磁盘碎片(非数据库碎片)

    平稳运行一年才出问题,假设这一年来业务系统查询没有发生大的变化,例如流量激增之类的。那么磁盘碎片需要考虑一下。如果是因为磁盘碎片的话,那么重启sql server或者清空缓存应该还能重现问题。


    Visit my tech blog: www.imkevinyang.com
    2011年10月21日 6:29
  • 建议定期重建索引,跟新统计信息;

    内存现在吃了多少? cpu 使用情况?

    2011年10月21日 6:29
  • SQLSERVER服务器总共32G内存。分给SQLSERVER12G
    内存现在使用到了15.3G。CPU 6% 这是现在的值

    恢复之前的值 分给SQLSERVER 24G

    2011年10月21日 6:42
  • 建议如果现在这个服务器不跑IIS 了,那给系统留2G,剩下的都给sql;

    主要查询的表的操作 如果有更新和删除操作,定期重建和组织索引;也可以尝试压缩表(会增加CPU 的使用);

    这种情况重现的话,查看 查询语句的等待状态 (如果因为长时间等待是pageiolatch_sh 表示在读硬盘 也就是缓存不足)具体的定位问题。

    2011年10月21日 7:31
  • 分配给sql 12G,那怎么会用到15.3G?

    你之前做过“调整内存分配,由原来的16G调整24G,然后又调整到8G,再调整到12G”

    这样就相当于清空了缓存,所以再次查询效率就会高很多了


    Visit my tech blog: www.imkevinyang.com
    2011年10月21日 7:55
  • SQL分配了12G。 现在整个服务器的内存用到了15.3G。

    2011年10月21日 8:43
  • 那问题会不会就算是因为内存的缘故呢?
    Visit my tech blog: www.imkevinyang.com
    2011年10月21日 8:45
  • 内存是其中一个问题。这点我们也发现了。
    可是我们将内存改到合适的值后,发现只要把IIS一打开(晚上10点,这时的流量几乎可以忽略不计),查询速度马上就上升到6-10秒,关掉IIS后20分钟后再查,并且清空缓存,几乎是瞬间就能查询出来。

    2011年10月21日 9:06
  • 内存是其中一个问题。这点我们也发现了。
    可是我们将内存改到合适的值后,发现只要把IIS一打开(晚上10点,这时的流量几乎可以忽略不计),查询速度马上就上升到6-10秒,关掉IIS后20分钟后再查,并且清空缓存,几乎是瞬间就能查询出来。

    如果是这样的话,那应该挺好排查的,很可能是web程序写得有问题,或者被人攻击,频繁的发起某些操作导致锁表之类的。

    用sql profiler或者ssms的activity monitor看看当前active的sql查询就行了。


    Visit my tech blog: www.imkevinyang.com
    2011年10月21日 9:09
  • 内存是其中一个问题。这点我们也发现了。
    可是我们将内存改到合适的值后,发现只要把IIS一打开(晚上10点,这时的流量几乎可以忽略不计),查询速度马上就上升到6-10秒,关掉IIS后20分钟后再查,并且清空缓存,几乎是瞬间就能查询出来。

    如果是这样的话,那应该挺好排查的,很可能是web程序写得有问题,或者被人攻击,频繁的发起某些操作导致锁表之类的。

    用sql profiler或者ssms的activity monitor看看当前active的sql查询就行了。


    Visit my tech blog: www.imkevinyang.com


    WEB程序排查有将近一月,而且将程序与SQL在另外一个业务地点带负载的运行,正常。所以排除WEB代码。

    系统构建在内网,而且使用过sql profiler查询过 当时的请求SQL,都是正常的业务。。所以可以排除恶意攻击。

    现在就是系统突然诡异的恢复了。麻烦在于不知道怎么恢复的,否则将来如果再出类似的事件,都不知从哪着手解决。

    2011年10月21日 9:16
  • 也就是说,你们现在无法再次重现这样的问题?如果是的话,那就比较棘手了。

    查一下windows应用程序日志以及群集日志,看看和sql server相关的是否有没有什么有用的信息。


    Visit my tech blog: www.imkevinyang.com
    2011年10月21日 9:22