是这样的,我们有个网站服务器,在用户访问并发达到20人(大约是这样)以上时候,网站的应用服务器(是tomcat5.5应用服务器,并使用它自己带的连接池)没事,但MSSQL服务在进程里占用cpu就100%导致服务器响应网站都很慢,几乎停止(但在无连续请求下,Cpu的占用情况,过一小时左右时间可以自己恢复正常。呵呵,问题很严重吧)。
从多方面找原因,一直没能找出问题所在。包含使用事件跟踪器,也没有跟踪到有sql脚本执行时间过长,后来用了一个不是办法的,把MSSQL服务器配置处理器为使用一个cpu(服务器为一个双核处理器),cpu再次显示最高占用时为50%,但想根本解决这个问题,请问我该怎么办?因为我担心如果cpu长期占用过高,会使温度过高,而导致机器自动关机,谁有相关经验,可以帮着分析一下,先谢谢了...
16 个解决方案
#1
这种问题多半是程序写的有问题
#2
gz!
#3
如果1秒分成20个周期,每个周期0.05S,那20个人不是正好不断占用CPU?
#4
如果补丁都打了的前提,
就是你数据结构或sql脚本的问题了
就是你数据结构或sql脚本的问题了
#5
LZ是你的程序有问题,请检查检查有关数据库连接的代码 进行测试看看
#6
看了大家的回复,多数是说程序方面问题可能性,但是我用事件探查器跟踪了两天了,并未发现有长时间占用执行的SQL脚本....
#7
程序出问题了.
#8
是否查询语句写的有问题,你把那个页面的所有查询语句拿到sql里直接运行,看cpu
#9
从上周五到今天(9.17周一)用事件探查器跟踪了一下,没有发现SQL脚本占用cpu过多情况
最长也只是400多,应该算正常的吧
最长也只是400多,应该算正常的吧
#10
label
#11
估计有死循环,详细检查程序和脚本
#12
呵呵,Dev-club的那个cpa2002?
#13
不是经常来技术论坛了,没想有人认出我,一时间被吓到了......- -!!
哈哈,剑公子好~~
哈哈,剑公子好~~
#14
先查毒。
估计是SQL语句效率太低导致CPU处理不过来。
估计是SQL语句效率太低导致CPU处理不过来。
#15
检查一下数据库连接情况
SQL写法(这个情况最多,因为SQL的写法很大程度上决定SQL性能与执行效率)
再则程序问题
SQL写法(这个情况最多,因为SQL的写法很大程度上决定SQL性能与执行效率)
再则程序问题
#16
多半是程序设计的问题,有死循环等操作,你是不是设置了触发器,如果有,请小心使用
#1
这种问题多半是程序写的有问题
#2
gz!
#3
如果1秒分成20个周期,每个周期0.05S,那20个人不是正好不断占用CPU?
#4
如果补丁都打了的前提,
就是你数据结构或sql脚本的问题了
就是你数据结构或sql脚本的问题了
#5
LZ是你的程序有问题,请检查检查有关数据库连接的代码 进行测试看看
#6
看了大家的回复,多数是说程序方面问题可能性,但是我用事件探查器跟踪了两天了,并未发现有长时间占用执行的SQL脚本....
#7
程序出问题了.
#8
是否查询语句写的有问题,你把那个页面的所有查询语句拿到sql里直接运行,看cpu
#9
从上周五到今天(9.17周一)用事件探查器跟踪了一下,没有发现SQL脚本占用cpu过多情况
最长也只是400多,应该算正常的吧
最长也只是400多,应该算正常的吧
#10
label
#11
估计有死循环,详细检查程序和脚本
#12
呵呵,Dev-club的那个cpa2002?
#13
不是经常来技术论坛了,没想有人认出我,一时间被吓到了......- -!!
哈哈,剑公子好~~
哈哈,剑公子好~~
#14
先查毒。
估计是SQL语句效率太低导致CPU处理不过来。
估计是SQL语句效率太低导致CPU处理不过来。
#15
检查一下数据库连接情况
SQL写法(这个情况最多,因为SQL的写法很大程度上决定SQL性能与执行效率)
再则程序问题
SQL写法(这个情况最多,因为SQL的写法很大程度上决定SQL性能与执行效率)
再则程序问题
#16
多半是程序设计的问题,有死循环等操作,你是不是设置了触发器,如果有,请小心使用