在IIS 10下运行ASP.NET应用程序的AppPool随机停止处理请求

doinxwow  于 2023-11-19  发布在  .NET
关注(0)|答案(1)|浏览(129)

我有一个奇怪的问题,它偶尔会出现-也就是说,它可能每天发生一次,甚至每隔几天发生一次-似乎是随机的。我已经确定这不是一个硬崩溃,因为这会在系统事件日志中留下一个与调用堆栈一起沿着的条目。它没有。
然而,它留下了一个警告说:
第一个月
这只是IIS工作进程健康检查的结果。
到目前为止,我已经能够捕获一次w3 wp进程,而它在这种状态下挂起了一分钟左右。我观察到它有一个异常高的CPU负载。它正在做一些事情,但没有什么有用的。它不接受也不处理任何新的请求,也没有自己记录任何事件(这通常应该每10秒左右在专用线程上发生一次)。
它看起来就像所有的线程都在忙碌,什么也不做,类似于通过一个无休止的while循环来消耗CPU。
我最终不得不回收池,正如预期的那样,它在一个新的w3 wp进程中剥离了一个新的应用程序示例。令我惊讶的是,旧进程一直在运行,直到我通过任务管理器手动杀死它。
我不知道一个ASP.NET应用程序怎么可能让自己进入这样的状态。
我所知道的唯一可能性是,如果应用程序的Bloc代码中存在一个bug,它不知何故设法产生了一个无休止的Bloc循环。据我所知,这不会导致StackOverflowException,因为线程在每个Bloc延续时都会切换。但它会(可能吗?)使线程池窒息,最终导致它耗尽空闲线程,并基本上停止进程对任何激励的响应。至少,这是我目前的假设。
但是我如何确认这一点呢?这涉及到大量的代码,而且到目前为止我们还没有可靠的可重复的案例。

6qfn3psc

6qfn3psc1#

为了子孙后代把这个贴出来。
看起来罪魁祸首是在某些涉及与PostgreSQL数据库通信的路径上缺乏ConfigureAwait(false)调用,特别是。有问题的应用程序也与Firebird和RavenDB通信,但这些路径没有受到影响。
目前,还不清楚是什么变化促使了这个突然的要求,多年来,这些相同的路径中不需要ConfigureAwait(false)调用就可以正常工作。
在代码提交的分析过程中,没有什么真正突出的。
我会继续观察,并试图确定原因。然而,现在,事情似乎是工作,终于。我会发布更新,如果有任何变化或新的证据曝光!

相关问题