ASP.NET 5 Web API 生产环境间歇无响应问题排查求助

优先排查连接池泄漏相关问题 #

• 首先检查连接字符串的Max Pool Size配置，默认值为100，若未手动调整，流量上涨后很容易触达应用端连接池上限，哪怕数据库本身连接数还有富余，也会出现获取连接超时的报错。
• 全量排查数据库访问代码，确认所有DbContext/数据库连接实例都正确释放，是否存在遗漏using块、异步方法中误用.Result/.Wait()导致连接被长时间持有不释放的情况。
• 故障发生时抓取应用进程的内存转储，统计MySqlConnection对象的存活数量和持有状态，确认是否有大量连接被未完成的请求挂住。

排查异步代码死锁问题 #

• 重点检查代码中是否存在async方法同步调用的情况，高并发下这类阻塞调用极容易触发线程池死锁，恰好符合故障时CPU、内存占用极低但所有请求挂起的特征。
• 确认全局异步配置是否关闭了SynchronizationContext捕获，局部await调用是否遗漏了ConfigureAwait(false)配置。
• 故障时查看IIS工作进程的线程数，若线程数长时间卡在固定阈值不再上涨，同时请求队列持续堆积，基本可以判定为线程池死锁。

IIS托管配置排查 #

• 检查IIS应用程序池的队列长度配置，默认值为1000，流量上涨后请求堆积容易触发队列满直接拒绝请求，可适当调高到5000观察故障是否复现。
• 检查应用程序池的快速故障防护配置，确认故障触发自动回收的阈值是否合理，避免进程挂起后需要等待很长时间才触发主动回收。
• 确认IIS请求超时限制是否合理，若存在长时间未结束的挂起请求占满请求槽位，也会导致新请求无响应。

后台服务异常排查 #

• 检查后台服务的异常捕获逻辑，是否存在后台任务抛出未处理异常导致进程挂起，或是后台任务意外占用大量线程池资源，导致前端请求无可用线程处理的情况。
• 确认后台服务是否存在数据库连接泄漏，长驻后台任务如果长期持有数据库连接不释放，会持续占用应用端连接池的配额。

临时验证方案 #

• 可先将连接字符串的Max Pool Size调整为200，同时给所有异步调用补充ConfigureAwait(false)配置，上线观察故障是否复现。
• 开启应用慢请求日志，记录所有耗时超过1s的请求路径和参数，缩小异常代码的排查范围。

内容的提问来源于stack exchange，提问作者Shawn Lehner