![尝试解决无响应/挂起/损坏的 IIS 网站时应采取哪些步骤?](https://linux22.com/image/555091/%E5%B0%9D%E8%AF%95%E8%A7%A3%E5%86%B3%E6%97%A0%E5%93%8D%E5%BA%94%2F%E6%8C%82%E8%B5%B7%2F%E6%8D%9F%E5%9D%8F%E7%9A%84%20IIS%20%E7%BD%91%E7%AB%99%E6%97%B6%E5%BA%94%E9%87%87%E5%8F%96%E5%93%AA%E4%BA%9B%E6%AD%A5%E9%AA%A4%EF%BC%9F.png)
当您发现 IIS 网站没有响应时,您会采取什么步骤?
我可能会尝试首先 telnet 到指定的端口,然后检查网站绑定和身份验证,最后重新启动它。
我认为了解经验丰富的管理员在遇到此类问题时会检查什么是非常有用的。
事实上,我自己花了半个多小时试图找出问题所在,但似乎没有什么不对劲。我只是重新启动了网站,问题仍然存在,但重新启动 IIS 服务后问题就解决了。
如果我能知道更好的跟踪或至少有用的日志记录功能以帮助我更快地解决问题,那将为我节省半个多小时。
{仅供参考,我正在使用 IIS 7.5}
答案1
我发现以下指导作为一般收集指南非常有效。
确定症状
尝试(尽快)确定问题的表面积:
连接性?(Telnet 很好;如果您在浏览器中看到返回的错误页面,则显然某些东西正在运行 - 请先消除连接)
常规应用程序池故障, 或者特定于内容类型?(ASPX 文件可以工作/不工作,但 .HTM 可以工作吗?您是否有针对每个应用程序和内容类型的金丝雀文件?)
特定的应用程序内故障、挂起或崩溃?(大部分都是针对挂起和应用程序故障;崩溃决定了它们自己的方法:获取崩溃转储,进行调试)
一般来说,一定要把它写下来,因为你可能要处理多种症状,而且能够参考你对早期事件的记录是非常有价值的。
收集数据
又称为“收集临时数据” - 在发生中断时,您只有有限的时间来收集某些数据。某些数据(如进程内存)是短暂的,如果您先采取纠正措施,它们就会消失。其他数据(如日志)可能需要一些时间来复制,但您可以轻松地在之后获取它们。因此,了解您现在需要收集哪些数据,以及恢复后需要收集哪些数据。
随便抓时间敏感/及时数据您需要稍后解决该问题。不要担心持久性的东西 - 事件日志和 IIS 日志会保留下来,除非您是一个强迫性清除者,在这种情况下:停下来。(那些没有上周事件日志的人注定会重蹈覆辙)
确定受影响的工作进程(然后丢弃)
APPCMD LIST WP
可以帮助解决这个问题,或者工作进程 GUI在服务器等级。如果使用 GUI,请不要忘记通过右键单击工作进程来查看当前请求 - 如果您得到它,它会向您显示请求被卡在哪个模块(DLL)中,这可以帮助您尽早猜测原因。
确定范围(即只有一个应用程序池,多个应用程序池,两个具有依赖关系的应用程序池 - 这取决于您的应用程序和网站布局)
获取内存转储的工作进程- 确定哪个应用程序池存在问题后,确定相关的工作进程,然后使用任务管理器通过右键单击该进程来创建内存转储。记下文件名以备后用。
- 注意任务管理器位数:您需要使用任务管理器的位数相同作为您攻击的工作进程 - 如果您使用 64 位任务管理器转储 32 位 WP (w3wp*32),它将无法解释。如果在 64 位 Windows 上转储 32 位进程,您需要退出任务管理器,运行 %WINDIR%\SYSWOW64\TaskMgr.exe 以获取 32 位版本,然后使用相同位数转储。(绕行十秒钟,但您必须当时这样做)。
恢复服务
现在,您已经获得了诊断所需的所有时间点信息,因此是时候让网站客户重新开始业务了。
回收这最小工作进程数以恢复服务。
不必费心停止和启动网站,通常需要刷新应用程序池才能使网站重新运行,这就是回收站所做的。
回收应用程序池9/10次就足够了。
请注意,回收似乎发生在下一个请求进来时(即使现有的 WP 已被告知消失),因此工作进程不得立即重新出现。这并不意味着它没有起作用,只是没有请求在等待。
IIS重置通常是不懂行的人使用的工具。不要使用它除非你需要所有网站同时终止并重新启动。(这就像试图用砖头把钉子钉进墙上。它可能会起作用,但你看起来像个白痴,而且在某个时候会有附带损害)。
您可能有其他应用程序依赖项 - 应用程序池依赖于其他应用程序池、数据库或外部系统... 您必须执行的操作才能恢复服务,这告诉您有关问题范围的信息。列表中的最后一个是完全重新启动,但除非内核级驱动程序真的搞砸了,否则这通常不是必要的,只是您无法确定哪些事情是必要的,这是一个有用的万能方法...
确定原因 即查看并思考您收集的数据。
- 获取日志和内存转储,寻找共同点,与应用程序开发人员联系,使用以下工具调试转储:调试诊断(或更新版本)或 WinDBG,等等。
为下次设置
您知道您已经修复了这个问题吗?如果没有,尤其是如果其他方面似乎没有变化,请考虑一下如果再次发生这种情况,您可以更好地做好准备,并记录下哪些信息。
不要以为这是最后一次- 制定计划为了下次你需要收集什么,以此时间为准。
例如,如果所有请求都针对同一个 URL,则需要实施一些额外的检测或日志记录,或者实施失败请求跟踪规则,以帮助识别页面上出现问题的位置。
性能监视器日志很有用(如果有疑问,也可以获取 perfmon 日志)。
看看其他可能有用的工具——ProcDump、XPerf/WPT/WPR 等等。如果你只有一把锤子,那么每个问题必须是钉子…
想想在寻找实际根本原因时“掩盖”问题是否可以接受 - 如果中断真的很严重,那么调整应用程序池的回收设置之类的操作可能是可以接受的,以尽量减少可能性或持续时间(除非这与能够解决问题相冲突)...
答案2
为什么绑定或身份验证方法(应该是静态的)会导致网站无响应?这些不在我的检查列表中,或者至少它们不在我的列表顶部。
我首先要检查的是网站是否能从服务器本身加载。如果不能,则可以排除几乎所有可能的网络或 DNS 问题。