.NET Web API请求超时或失败：如何诊断与修复？

核心症状复盘 #

• 部分请求超时后失败，部分直接返回500 Internal Server Error
• 日志仅偶现超时异常，无明确错误栈信息
• SQL Server连接间歇性断开，可自行恢复
• 问题发作时服务器内存占用过高
• 多并发场景下失败模式无规律

已排查动作确认 #

• 启用日志未定位根因，偶发API无响应
• 延长客户端/服务器超时时间无效
• 优化慢SQL查询（添加索引）后问题持续

下一步针对性排查方案 #

1. 内存泄漏专项排查 #

既然问题发作时内存占用过高，优先锁定内存泄漏点：

• 使用dotnet-dump或Visual Studio内存分析工具，抓取问题发生时的内存快照，分析对象引用链，定位未释放的资源（如数据库连接、HttpClient实例、静态集合等）
• 检查所有SqlConnection是否用using语句包裹，避免连接池耗尽（连接池耗尽会导致后续请求等待连接超时，甚至触发500错误）
• 排查第三方组件（如缓存、日志框架）是否存在内存泄漏情况

2. SQL连接问题深度定位 #

SQL连接自行恢复但间歇性断开，需从连接池和数据库端双向排查：

• 检查连接字符串配置：确认Max Pool Size（默认100）是否适配并发量，同时核对Connection Timeout和Command Timeout设置是否合理
• 启用SQL Server扩展事件或SQL Server Profiler，捕捉连接断开的具体触发原因（如数据库端主动踢连接、TCP层面异常断开）
• 检查HTTPS连接的TLS握手情况：高并发下TLS握手队列耗尽也会导致请求超时，可查看Windows事件日志中的Schannel事件
• 排查SQL Server死锁/阻塞：即使优化了慢查询，高并发下的锁竞争仍可能导致请求超时，通过sp_who2或sys.dm_tran_locks查看实时锁状态

3. API线程池与请求队列排查 #

多并发下API无响应，可能是线程池耗尽导致：

• 使用dotnet-counters实时监测线程池线程数、队列长度，确认是否达到上限（默认线程池最小线程数为CPU核心数*2）
• 检查代码中是否存在同步阻塞异步代码的情况（如在async方法中调用.Result/.Wait()），这会占用线程池线程，导致无法处理新请求
• 配置Kestrel的MaxConcurrentConnections和MaxConcurrentUpgradedConnections参数，避免连接数超出服务器处理能力

4. 500错误的隐式日志补全 #

日志无明确错误信息，需加强全局异常捕获：

• 在Program.cs中配置全局异常中间件，捕获所有未处理异常并记录完整错误栈（含内部异常）：

app.UseExceptionHandler(errorApp =>
{
    errorApp.Run(async context =>
    {
        var exceptionFeature = context.Features.Get<IExceptionHandlerPathFeature>();
        var exception = exceptionFeature?.Error;
        
        logger.LogError(exception, "Unhandled exception at {Path}", exceptionFeature?.Path);
        
        context.Response.StatusCode = StatusCodes.Status500InternalServerError;
        await context.Response.WriteAsJsonAsync(new { Message = "An unexpected error occurred" });
    });
});

• 启用.NET EventSource日志，捕获框架层面的内部错误（如Kestrel连接异常、SQL连接池错误）

5. 服务器资源瓶颈排查 #

• 实时监测CPU、磁盘IO、网络带宽：内存过高可能是CPU不足导致GC频繁，或磁盘IO瓶颈引发数据读写延迟
• 查看Windows系统事件日志，确认是否存在内存不足、磁盘空间不足、TCP连接耗尽等警告
• 检查服务器是否开启内存压缩或页面文件，内存不足时页面文件交换会导致性能骤降

内容的提问来源于stack exchange，提问作者Dina Mohammed