整容说文库 > 程序代码 > 教育资讯

我的SQL SERVER为什么如此消耗资源?

来源:学生作业帮助网 编辑:整容说文库 时间:2019/09/15 21:54:09 程序代码
我的SQL SERVER为什么如此消耗资源?程序代码
我的服务器是双CPU(单个CPU为P4的2个G),1.5G内存,现在主要运行着一个论坛和一个博客,我的论坛是由动网的6.0修改的存储过程版本,另外博客是在论坛的基础上增加的,同时在线在500、600人左右;
最近发现有时候速度越来越慢,一查才知道,大量的CPU时间和大量的内存都在SQL上消耗着,有时候CPU峰值会到60%,甚至80%,到是很快可以下到10%,上到那么高多数时间是爆发上去的,内存在SQL上消耗了1.1个G;
然而从SQL管理器中看进程,发现同时并发的数据库查询并不多,大多时候是一个或者两个处于活动状态,另外还有7、8个处于休眠状态的;

请问老师,您看这个问题一般会是什么情况造成的,应该如何解决

是应该增加一台服务器做负载均衡吗?
mark!
同时对数据库操作?

^_^
分析性能缓慢问题的技术 


只通过系统级服务器性能的调整就能解决性能问题是很诱惑人的。例如,内存大小、文件系统类型、处理器数量和类型等等。Microsoft SQL Server 支持小组的经验表明,大多数问题无法通过这一方式解决。必须通过分析应用程序、应用程序提交给数据库的查询、以及这些查询如何与数据库架构进行交互,这些问题才能得到解决。 

首先,将速度很慢的查询隔离出来。通常整个应用程序看起来都很慢的情况下,实际只有少数 SQL 查询很慢。不对问题作细致分解并隔离慢速的查询,性能问题往往无法解决。如果您用的是透明生成 SQL 的开发工具,请用该工具的诊断或调试模式来捕获生成的 SQL。很多情况下还有一些跟踪功能可用,但它们可能没有被公开。请与应用程序的技术支持联系,以确定有没有可监视应用程序生成的 SQL 语句的跟踪功能。 

对于那些使用嵌入式 SQL 的应用程序开发工具来说,这要容易的多,因为 SQL 是可见的。 

如果您的开发工具或最终用户应用程序没有提供跟踪功能,则还有几种备用方法可供选择: 
• 根据 SQL Server 4.2x“Troubleshooting Guide”和 SQL Server 6.0“Transact-SQL Reference”的说明使用 4032 跟踪标记。这将在 SQL 错误日志中捕获发送到服务器的 SQL 语句。  
• 通过像“Microsoft 网络监视器”(它是 Systems Management Server 的一部分)这样的网络分析程序来监视查询。  
• 对于 ODBC 应用程序,使用 ODBC Administrator 程序来选择跟踪 ODBC 调用。要获取更详细的信息,请参见 ODBC 文档。  
• 使用在 DB-Library 或 ODBC 层截获 SQL 的第三方客户端工具。Blue Lagoon Software 的 SQL Inspector 便是一个例子。  
• 使用 Microsoft TechNet CD 中作为示例提供的 SQLEye 分析工具。备注:SQLEye 不在 Microsoft 技术支持范围之内。  
在隔离了慢速查询后,执行以下操作: 
• 使用 ISQL 之类的查询工具,孤立地运行被怀疑速度很慢的查询,对其实际速度进行验证。最好的做法是用 ISQL 及本地管道在服务器计算机上运行查询,然后再把输出重定向到文件中。这有助于去除复杂的因素(如网络和屏幕 I/O),以及应用程序结果缓冲的影响。  
• 通过 SET STATISTICS IO ON 来检查查询占用的 I/O。 注意逻辑页 I/O 计数。优化程序的目标是使 I/O 计数最小。记录逻辑 I/O 计数。这将成为衡量性能改善的基线。比起 SET SHOWPLAN ON,专门关注 STATISTICS IO 输出,并试验不同的查询和索引类型,会更为有效。解释并有效地应用 SHOWPLAN 输出要求作一些研究工作,把它占用的时间花在一些试验性测试上可能效率更高。如果这些简单的建议还不能解决性能问题,您可以使用 SHOWPLAN 对优化程序行为作更彻底的调查。  
• 如果查询涉及一个视图或存储过程,把它从视图或存储过程提取出来单独运行。在您尝试不同的索引时,这将允许对访问计划作出更改。这还有助于把该问题定位在查询本身,而不是优化程序如何处理视图或存储过程。如果问题并不在于查询本身,而是存在于查询作为视图或存储过程的一部分运行时,那么独立地运行查询也将有助于确定这一点。  
• 注意查询涉及的表上可能存在的触发器,它们在运行时会产生明显的 I/O。您应该把慢速查询中涉及的触发器删除掉。这将有助于确定问题究竟是在查询本身,还是在触发器或视图上,从而确定您努力的方向。  
• 检查慢速查询用到的表的索引。通过上面列举的技术来确定这些索引是否合理,并对它们作必要的修改。您努力的第一步应是对 WHERE 子句中的每一列进行索引。通常,性能问题是由于 WHERE 子句中的列没有进行索引,或者这些列上没有有效的索引而引起的。  
• 用上面提到的查询来检查 WHERE 子句中提到的每一列(尤其是每一索引列)的数据唯一性和分布。在很多情况下,只需对查询、表、索引和数据作简单的检查,马上就能看到问题的起因。例如,性能问题经常是由于对一个只有 3 个或 4 个唯一值的关键字进行了索引,或在这样的列上执行了联接,或把过多的行数返回给客户造成的。  
• 在这些研究的基础上,对应用程序、查询或索引作很必要的更改。完成修改后,再次运行查询,并观察 I/O 计数的变化。  
• 如果发现速度有所提高,请运行主应用程序,看看整体性能有没有提高。  
检查程序受 I/O 或 CPU 限制的行为方式。通常,确定某查询是不是受 I/O 或 CPU 限制非常有用。这有助于把提高性能的努力集中在真正的瓶颈上。例如,如果某个查询是受 CPU 限制的,那么给 SQL Server 添加再多的内存也不会明显改善它的性能,这是因为更多的内存只能改善高速缓存命中率,而在这里,它本来就已经是很高了。 

如何检查 I/O 受限与 CPU 受限的查询行为: 
• 用 Windows NT 性能监视器来监视 I/O 与 CPU 的活动。 监视 LogicalDisk 对象“% Disk Time”计数器的所有实例。同时监视 System 对象的“% Total Processor Time”计数器。要查看有效的磁盘性能信息,您必须先从命令提示符发出“diskperf -Y”,打开 Windows NT DISKPERF 设置,然后重新启动系统。详细信息请参见 Windows NT 文档。  
• 查询运行时,如果 CPU 图形曲线一直很高(比如,高于 70 %),而 % Disk Time 一直很低,说明这是一个 CPU 受限的状态。  
• 查询运行时,如果 CPU 图形曲线一直很低(比如,低于 50 %),而 % Disk Time 一直很高,说明这是一个 I/O 受限的状态。  
• 把 CPU 图形与 STATISTICS IO 信息进行比较。  
SQL Server 在大型数据库中可以有很好的性能。在 SQL Server 6.0 中更是如此。为了实现这种性能潜力,您必须使用有效的数据库、索引、查询和应用程序设计。从这几个方面,最有可能获得显著的性能改善。让每一个查询都尽可能地有效,这样当应用程序扩展到更多的用户时,可以支持集团多用户负载。我们鼓励您使用本文提供的指导方针对客户应用程序的行为、应用程序提交的查询进行必要的研究,并对不同的索引进行试验。分析性能问题的方法,通常可以通过投入相对较少的时间,产生显著的性能改善。
首现我也要关注中(因为我也要做公网服务器了)

我帮你分析的:
1、打OS和DB的SP了吗?
2、打开检查器,CPU高速时,是不是有大量的查询操作
3、装防火防毒的软件了吗?
4、是不是,还有其它软件在运行?
1.查看一下訪問的用戶是不是太多?
2.是不是數據庫正在備份?
答softj(天地客人) :

OS和DB的SP打了
SQL管理器中看进程,CPU高速时也就1、2个并发的查询进程
装了诺顿
没有其他软件运行
------------------------------------------------------

答hdhai9451(New New People---新新人类) :

访问人数还是有一些的, 因为40分钟内在线500、600多人
数据库备份我设置是在凌晨2点,不可能一直备份

日志有2个G,是因为日志过大拖慢了速度吗?
程序代码