IIS应用程序突然失败,出现503响应,但没有事件日志条目

g0czyy6m  于 6个月前  发布在  其他
关注(0)|答案(1)|浏览(83)

在我们公司,我们有一个ASP.NET 7 Razor Pages应用程序托管在Windows Server 2016上的IIS 10上。我们在公司的多个工厂有多个此软件的示例。只有一台服务器上,我们不时(每周1-2次)的问题,应用程序从一个时刻到另一个时刻只是返回“此服务不可用”和503响应。似乎应用程序池被停止,但是当在IIS中查看时,它仍然在运行。此外,托管服务不定期地继续工作,因为我们仍然可以看到来自它们的日志条目。所以这似乎是一个IIS问题。
只有在手动回收应用程序池后,网站才能正常工作。在此之后,起初一切正常,29小时后自动回收也正常。但随后,再过2-5天的随机时间,它将再次失败,并返回503响应。
Windows事件日志不包含任何信息。当Web应用程序卡住时,没有错误或警告。只有当我们手动回收应用程序池时,才会有来自源“IIS AspNetCore Module V2”的条目报告关闭,然后成功重新启动。
如前所述,具有相同版本的完全相同的软件在其他服务器上运行良好。在失败的服务器上,还有其他Web应用程序,没有同样的问题。失败的软件用于正常工作超过3年,并开始表现奇怪突然几个星期前没有任何apparant变化。
应用程序池的标识正常,未被阻止。应用程序池的设置方式与所有其他应用程序池相同。我们已仔细检查了所有属性。
在Web应用程序失败之前向IIS发出的请求数量是正常的,我们也检查了这些日志。
我们的内部应用程序日志记录所有已处理的异常,但不输出任何内容。
服务器资源也还可以,CPU负载只有10-25%t,可用内存7 GB。
我们很高兴每一个建议,我们可以继续搜索,因为我们已经用完的想法。

cigdeys3

cigdeys31#

当服务器挂起或崩溃时,通常需要捕获服务器的线程堆栈(线程转储)以供后续分析。
调试诊断工具(Debug Diag)可以是一个救星。您可以参考:IIS Application Pool Crash and Debug Diag。它创建并分析IIS崩溃转储。在查看调用堆栈后,您可能能够找出崩溃的原因。
但是分析转储文件是一个复杂的过程,所以我建议你通过:https://support.microsoft.com打开一个案例,会有专业的技术人员帮助你抓取转储文件并进行分析。

相关问题