IIS7网站检测

昨天夜里两点，站检我盯着屏幕上那个刺眼的站检“500 Internal Server Error”，差点把咖啡泼在键盘上。站检新上线的站检活动页面挂了，客户电话已经打爆了三个。站检FTP连上去，站检文件都在，站检权限没错，站检数据库连接字符串也核对过三遍。站检

问题出在哪？站检最后是同事老张一句话点醒我：“你查过应用程序池没？”

IIS7里的应用程序池，这东西平时根本没人注意，站检但一旦出问题，站检它能让整个网站像死鱼一样翻白眼。站检我打开IIS管理器，站检右键点击那个罪魁祸首的站检池——果然，状态是“已停止”。重启，页面秒开。就这么简单，却让我折腾了整整一小时。

说回IIS7本身。相比老掉牙的IIS6，它的架构整个推倒重来了。最大的变化是配置系统从Metabase（那个让人抓狂的二进制数据库）换成了纯XML文件——applicationHost.config。这意味着你可以直接改文件、用Git做版本管理、甚至写脚本批量修改配置。我见过不少人还在用IIS6时代的老思路，遇事不决就重启服务器，其实在IIS7里，八成问题都能在站点级别就解决掉。

检测IIS7网站，我一般按这个顺序来。先看站点绑定的端口和主机头，很多“网站打不开”的假象，其实是域名解析没生效或者绑定了错误的IP。然后打开“处理程序映射”，确认ASP.NET的版本是否匹配——IIS7默认集成模式，如果你用的是Classic模式的老代码，某些HttpModule会静默失效，页面能开但功能全乱。

再往下就是日志了。别嫌麻烦，C:\inetpub\logs\LogFiles里的W3C日志是宝贝。上次有个客户反馈后台偶尔登不进去，我翻日志发现每小时的某个整点时刻，请求量骤增导致连接池耗尽——后来查出来是某个定时任务在作怪。这种问题，靠猜永远猜不到，日志一翻就现形。

还有个小细节容易被人忽略：应用程序池的“回收”设置。默认情况下IIS7会在固定时间间隔（通常是1740分钟）自动回收进程，这本是好事，但如果你的站点里有长时间运行的任务（比如上传大文件），回收动作会直接掐断它。我习惯把“特定时间回收”改成凌晨四点，避开业务高峰。

说实话，IIS7的检测工具不少，自带的appcmd命令比图形界面好用十倍。比如appcmd list sites能一眼看到所有站点的状态和绑定，appcmd recycle apppool /apppool.name:xxx可以远程重启池——比RDP连上去点鼠标快多了。我手机上装了个远程SSH客户端，半夜被叫醒时，直接敲命令重启，不用开电脑。

最后提一句性能监控。Windows自带的性能监视器里加几个计数器：ASP.NET\Requests Current、Process\Working Set、Web Service\Current Connections。数值异常时，基本能判断是内存泄漏还是请求堆积。比装一堆商业监控软件实在。

干这行久了你会发现，IIS7的脾气其实挺直来直去。它不像Linux下那些配置复杂的Nginx，也不像Apache的.htaccess弯弯绕绕。它出问题，八成是配置文件的某个节点写错了，或者应用程序池在闹情绪。你只要摸清它的脾气，检测起来就是几分钟的事。当然，前提是——你记得先看应用程序池。