通过IIS Request Filtering解决SQL Server CPU高的问题

原文http://www.peterviola.com/solving-sql-server-high-cpu-with-iis-request-filtering/

Top Queries by Total CPU Time

当CPU非常高的时候有可能你的条件反射就是重启服务或者回收App Pools.SQL Server 2008 内置了非常棒的报表帮助我们追踪CPU的使用情况. 我使用Top Queries by Total CPU Time 报表. 如下图一项 右键服务名选择相应的报表.

Top Queries by Total CPU Time 报表会需要一点时间来生成. 通过报表能够获得是哪10个数据的查询消费了最多的CPU. 通过报表我们发现这个服务器上的一个数据库的4个不同query消耗的大部分CPU.

SQL Profiler and Database Tuning Advisor

现在我知道是哪个数据库引发高CPU的问题了, 启动 SQL Profiler 几分钟收集下数据.可以看到高的Reads是从 “Internet Information Services” 这个Appliation发出来的.

在将注意力集中在网站之前,我想看看通过 Database Engine Tuning Advisor  能不能提高效率 DTA 会分析通过提供的SQL脚本 分析数据的一些行为,并且提高一个优化的方案(包括使用索引,分区...). 通常通过 DTA  我们能提高 5-10 % 的性能改善. 在这个案例中我们能看到提高了97% 的改善!

Preventing SQL Injection with IIS Request Filtering

通过执行DTA提高的优化脚本能降低一些CPU了. 然而我知道我们的网站有可能正在遭受一些可疑的访问所以我使用 Log Parser 获得一些网站的访问情况.通过下面的query发现打量的访问是正在利用querystring进行SQL注入.

logparser.exe -i:iisw3c “select top 20 count(*),cs-uri-query from ex140702.log

group by cs-uri-query order by count(*) desc” -rtp:-1 >file.txt

通常我们倾向于屏蔽攻击的IP. 不幸的是一些老道的攻击会使用大量不同的IP对你进行攻击. 最佳的解决方案是通过 Request Filtering 过滤屏蔽这些恶意的请求.

通过 IIS Request Filtering 我们阻止了SQL注入攻击. 使用下面Log Parser的查询我们能看到所有请求的 http status codes .

SELECT STRCAT(TO_STRING(sc-status), STRCAT(‘.’, TO_STRING(sc-substatus))) AS Status, COUNT(*)

AS Total FROM w3svc.log to TopStatusCodes.txt GROUP BY Status ORDER BY Total DESC

当一个querystring被拒绝的时候Request Filtering 会使用 http substatus 404.18 . 通过下面的Log Parser report 能看到  50,039 个请求被屏蔽了.

时间: 2024-11-09 05:50:13

通过IIS Request Filtering解决SQL Server CPU高的问题的相关文章

解决SQL Server 阻止了对组件 'Ad Hoc Distributed Queries' 的 STATEMENT'OpenRowset/OpenDatasource' 的访问的方法

报错内容是:SQL  Server 阻止了对组件 'Ad Hoc Distributed Queries' 的  STATEMENT'OpenRowset/OpenDatasource'  的访问,因为此组件已作为此服务器安全配置的一部分而被关闭.系统管理员可以通过使用 sp_configure 启用 'Ad Hoc  Distributed Queries'.有关启用 'Ad Hoc Distributed Queries' 的详细信息,请参阅 SQL  Server 联机丛书中的 "外围应用

解决 SQL Server 连接到服务器 错误223

我的SQL Server2005 一直正常使用但昨天出现了错误,如图. 经过上网查,网上说的办法试了好多都没有解决这个问题.在经过多次的摸索后终于搞定了,答案很简单,是sql身份验证 “sa”账号 登录密码的问题. 但是前提是你必须得保证你的sql server 的sql 身份验证可以用,所以在这里我们就先给大家讲述下怎样使sql身份验证可以启用(sql server身份验证可以用的直接跳过这一步). 首先用windows身份验证登录,windows身份验证不可以登录的请看我前面博客“解决SQL

解决SQL Server管理器无法连接远程数据库Error: 1326错误

解决SQL Server管理器无法连接远程数据库Error: 1326错误 我们在在使用SQL Server时都会遇到使用SQL Server Management Studio无法连接远程数据库实例的问题,错误描述信息摘录如下: An error has occurred while establishing a connection to the server. (provider: Named Pipes Provider, error: 40 – Could not open a con

解决 SQL Server 耗尽内存的情况

如果您碰到SQL Server服务造成内存不断扩展最终系统死机等情况,请按照以下方法解决. 原理:SQL Server 2000引入的动态内存分配机制,一般不能很好的回收内存,如果计算机一直不关闭,就会发生内存耗尽的可能.您可以选择每周关机一次来避免,或者是按照下述方法来抑制内存的增长. 1.在服务器上开始—Microsoft SQL Server—企业管理器 中启动SQL企业管理器 2.启动以后打开右边的控制台树:控制台根目录\Microsoft SQL server\Sql Server组\

解决SQL Server 阻止了对组件 'Ad Hoc Distributed Queries' 的 STATEMENT 'OpenRowset/OpenDatasource' 的访问

根据需要进行asp.net的数据导入导出,结果报以下错: SQL Server 阻止了对组件 'Ad Hoc Distributed Queries' 的 STATEMENT 'OpenRowset/OpenDatasource' 的访问,因为此组件已作为此服务器安全配置的一部分而被关闭.系统管理员可以通过使用 sp_configure 启用 'Ad Hoc Distributed Queries'.有关启用 'Ad Hoc Distributed Queries' 的详细信息,请参阅 SQL

【半转贴】解决SQL SERVER 2008数据库表中修改字段后不能保存

SQL SERVER 2008数据库表中修改字段后不能保存,这种情况将阻止保存要求重新创建表的更改一项的钩钩去掉就OK了 找到工具>选项>Designers>表设计器和数据库设计器 然后将“阻止保存要求重新创建表的更改” 的这一项的钩钩去掉就OK了 图片来自:http://www.jb51.net/article/42727.htm 刚好碰到这个问题,用的就是上面的方法解决的 [半转贴]解决SQL SERVER 2008数据库表中修改字段后不能保存

解决 SQL Server 所有帐号无 sysadmin 权限,且未启用 SQL Server 身份验证,sa 帐号也未启用的问题

解决 未启用 SQL Server 身份验证 的问题: 1. 运行 regedit,进入注册表编辑器 2. 打开:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQLServer( MSSQL14.MSSQLSERVER 这部分根据实际安装实例的名称来选择,若有多个实例,请打开需要设置的那个) 3. 找到其中的 LoginMode 项,值为 1 时仅 Windows 身份验证,值为

Sql Server 高频,高并发访问中的键查找死锁解析

死锁对于DBA或是数据库开发人员而言并不陌生,它的引发多种多样,一般而言,数据库应用的开发者在设计时都会有一定的考量进而尽量避免死锁的产生.但有时因为一些特殊应用场景如高频查询,高并发查询下由于数据库设计的潜在问题,一些不易捕捉的死锁可能出现从而影响业务.这里为大家介绍由于设计问题引起的键查找死锁及相关的解决办法. 这里我们在测试的同时开启trace profiler跟踪死锁视图(locks:deadlock graph).(当然也可以开启跟踪标记,或者应用扩展事件(xevents)等捕捉死锁)

SQL Server CPU

解决数据库系统的性能问题可能是一项艰巨的任务.了解如何找到问题很重要,但是了解系统对特定请求作出特定反应的原因更加重要.影响数据库服务器上的 CPU 利用率 的因素有很多:SQL 语句的编译和重新编译.缺少索引.多线程操作.磁盘瓶颈.内存瓶颈.日常维护以及抽取.转换和装载 (ETL) 活动和其他因素.利用 CPU 本身并不是一件坏事情,执行任务是 CPU 的职责所在.CPU 利用率正常的关键是确保 CPU 处理您需要它处理的任务,而不是将循环浪费在不良优化的代码或缓慢的硬件上. 达到同一目的的两