解决方案1:
现象：机器在调试或允许iis时，服务异常中断(如断电)，然后IIS再次运行页面时，CPU资源占用100%，即使重启也无效。
原因：当出现中断时，IIS会写异常日志，但此时写的是乱码，导致IIS不断写日志的死循环，耗尽系统资源。在系统路径\System32\Logfiles\W3SVC1下找到当天的错误日志文件。
可以看到上面的内容。
解决方法：删除系统路径\System32\Logfiles\W3SVC1下当天的错误日志文件，如ex060904.log，然后重新启动IIS。
解决方案2:
Environment: win 2003 server IIs ASP MSSQL
现象：每隔一段时间(不定，有时几分钟，有时半小时)，网站打开很慢，有时超时打不开。这时候你看服务器端的进程，CPU利用率达到100%，其中w3wp占据70~80%。
SQL占20~30%。所有服务器端操作也变得缓慢。
初步解决方法：每次现象出现，立即登录服务器直接结束w3wp进程或者重启IIS服务，平均每天十次左右。因为服务器存放在远程机房，所有操作都是远程控制，有时无法远程登录。
我们只能电话通知机房管理员重启服务器，导致用户投诉不断。
在网上查阅资料后发现，这些现象大多是由于网页代码不合理造成的，以下情况会导致此类现象：
1.代码中很多地方使用了application、seesion等服务器缓存，导致服务器数据的过度使用；
2.代码语法不合理，无限循环等。
3.数据库损坏，尤其是access数据库；
4.安装了太多第三方软件或插件，与IIS或网页功能代码冲突。
调查的第一阶段：根据查阅的参考资料逐一分析。
1.服务器上所有的站点代码都是公司的设计师自己写的，证明服务器缓存语法没有调用太多(排除)。
2.代码是否有不合理的语法(不确定性)
3.根据情况，当IIS进程占用率上升时，SQL占用率也同时上升，应该是SQL数据库的站点。根据现象，库或表应该是正常的，估计数据可能有误差；(不确定)
4.服务器端除了基本的系统服务、杀毒、网站运营必备服务之外，没有多余的第三方软件，这种可能性不大(排除)。
经过以上分析判断，结合不确定项得出结论：某网站使用SQL数据库的网页代码存在不合理的语法，导致IIS和SQL进程的CPU占用率较高。
调查的第二阶段：
确定范围，然后继续缩小。
因为服务器上使用SQL数据库的站点不多，所以建立独立的进程ID便于观察。所有使用SQL数据库的站点都在IIS管理器中设置独立的应用程序池。
然后通过CMD界面输入：iisapp -a 命今查看并记录下各IIS池的进程ID号，通过多次现象重现时的观察，有个IIS进程ID是导致此次问题的罪魁祸首。
解决方案3：
在IIS6下，经常出现w3wp.exe的内存及CPU占用不能及时释放，从而导致服务器响应速度很慢。
解决内存占用过多，可以做以下配置：
1、在IIS中对每个网站进行单独的应用程序池配置。即互相之间不影响。
2、设置应用程序池的回收时间，默认为1720小时，可以根据情况修改。再设置当内存占用超过多少（如500M），就自动回收内存。
解决CPU占用过多：
1、在IIS中对每个网站进行单独的应用程序池配置。即互相之间不影响。
2、设置应用程序池的CPU监视，不超过25%（服务器为4CPU），每分钟刷新，超过限制时关闭。
根据w3wp取得是那个一个应用程序池：
1、在任务管理器中增加显示pid字段。就可以看到占用内存或者cpu最高的进程
2、在命令提示符下运行iisapp -a。注意，第一次运行，会提示没有js支持，点击确定。然后再次运行就可以了。这样就可以看到pid对应的应用程序池。
（iisapp实际上是存放在C:\windows\system32目录下的一个VBS脚本，全名为iisapp.vbs，如果你和我一样，也禁止了Vbs默认关联程序，那么就需要手动到该目录，先择打开方式，
然后选“Microsoft (r) Windows Based Script Host”来执行，就可以得到PID与应用程序池的对应关系。）
3、到iis中察看该应用程序池对应的网站，就ok了，做出上面的内存或CPU方面的限制，或检查程序有无死循环之类的问题。