解决方案1:
现象：机器在调试或允许iis时，服务异常中断(如断电)，然后IIS再次运行页面时，CPU资源占用100%，即使重启也无效。
原因：当出现中断时，IIS会写异常日志，但此时写的是乱码，导致IIS一直写日志的死循环，耗尽了系统资源。在系统路径\System32\Logfiles\W3SVC1下找到当天的错误日志文件，可以看到上面的内容。
解决方法：删除系统路径\System32\Logfiles\W3SVC1下当天的错误日志文件，如ex060904.log，然后重启IIS。
解决方案2:
环境：win 2003服务器IIs ASP MSSQL
现象：每隔一段时间(有时几分钟，有时半小时)，网站打开非常慢，有时超时后网站打不开。此时CPU利用率达到100%，其中w3wp占70~80%，SQL占20~30%。所有服务器端操作也变得缓慢。
初步解决方案：每次出现现象，立即登录服务器直接结束w3wp进程或者重启IIS服务，平均每天十次左右的操作。因为服务器存放在远程机房，所有操作都是远程进行，有时会出现远程登录连接不上的情况。只能电话通知机房管理员重启服务器解决问题。这个过程导致用户不断抱怨。
在网上查阅资料后发现，这些现象大多是由于网页代码不合理造成的。以下情况会导致这种现象：
1.代码中很多地方使用了application、seesion等服务器缓存，导致对服务器数据的过度占用；
2.代码有语法不合理，无限循环等。
3.数据库损坏，尤其是access数据库；
4.安装了太多第三方软件或插件，与IIS或网页功能代码冲突。
调查的第一阶段：根据查阅的参考资料进行逐项分析。
1.服务器上所有的站点代码都是公司的设计师自己写的，可以确认的是服务器缓存语法(exclusion)没有调用太多。
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其实是一个Vbs脚本，存储在C:\windows\system32目录下，全名是iisapp.vbs，如果你和我一样，也禁用了vbs默认关联程序，那么你需要手动转到这个目录，先选择打开方式，然后选择“Microsoft(R)Windows Based Script Host”执行，就可以得到PID和应用池的对应关系了。)
3.在iis中查看应用池对应的网站，就可以了。对内存或CPU做以上限制，或者检查程序是否有无限循环之类的。
