ASP.NET应用突发性能下降求助：需定位问题及排查工具（含linked server）

我来分享几个针对你这种场景的实用排查思路和替代监控工具，毕竟遇到过不少和链接服务器相关的隐性性能坑：

一、替代AppDynamics的监控工具 #

• New Relic：和AppDynamics同类型的全链路APM工具，能深度追踪跨数据库（包括链接服务器）的调用链，甚至可以定位到分布式事务的延迟节点，对ASP.NET的性能计数器和代码执行路径监控也很全面
• Azure Monitor（应用洞察）：如果你的应用部署在Azure上，这个工具是天然适配的，能结合ASP.NET的请求追踪、SQL查询分析，还能专门监控链接服务器的跨实例流量和延迟
• JetBrains dotTrace/dotMemory：可以本地或远程attach到ASP.NET进程，精准追踪.NET代码的执行耗时，排查线程阻塞、资源泄漏（比如链接服务器连接池耗尽）这类问题，适合深入代码层面分析
• SQL Server Extended Events：相比老的Profiler更轻量，能精准捕获链接服务器的所有远程查询，包括远程服务器上的执行计划和耗时，是排查跨服务器查询性能的利器

二、重点针对链接服务器的排查方法 #

既然你已经排除了本地存储过程和常规数据库调用的问题，链接服务器大概率是核心疑点，试试这些步骤：

1. 检查链接服务器连接池状态
   执行以下SQL查询，查看链接服务器的连接数、等待状态：

   SELECT 
       c.session_id,
       c.connect_time,
       c.last_read,
       c.last_write,
       s.host_name,
       s.program_name
   FROM sys.dm_exec_connections c
   JOIN sys.dm_exec_sessions s ON c.session_id = s.session_id
   WHERE c.net_transport = 'TCP' 
     AND c.remote_net_address IS NOT NULL; -- 筛选链接服务器的连接
   

   如果发现大量长时间未释放的连接，可能存在连接泄漏，检查代码中是否正确关闭了链接服务器的相关连接。

2. 验证远程查询的实际性能
   不要只看本地存储过程的执行时间，直接在远程服务器上执行对应的查询，看实际耗时。很多时候本地存储过程调用链接服务器时，会把远程表全量拉到本地再过滤，导致大量数据传输延迟。可以用OPTION (RECOMPILE)强制生成远程执行计划，或者修改查询逻辑让筛选条件推送到远程服务器。

3. 排查分布式事务阻塞
   如果存储过程中使用了分布式事务（BEGIN DISTRIBUTED TRANSACTION），事务的提交/回滚可能因网络或远程服务器问题卡住，导致线程阻塞。执行以下查询查看分布式事务状态：

   SELECT 
       transaction_id,
       name,
       transaction_begin_time,
       transaction_state
   FROM sys.dm_tran_active_transactions
   WHERE transaction_type = 4; -- 分布式事务
   

   同时查看锁状态，确认是否有跨服务器的锁等待。

4. 监控ASP.NET线程池与请求队列
   打开Windows性能计数器，关注以下指标：

   • .NET CLR Threads -> ThreadPool Thread Count：如果线程数持续高位，说明线程池被占满，链接服务器的慢调用可能长时间占用线程，导致后续请求排队
   • ASP.NET -> Requests Queued：队列长度持续增加，说明应用无法及时处理请求，大概率是线程资源不足

5. 检查链接服务器配置与网络

   • 测试手动执行链接服务器的简单查询（比如SELECT * FROM [LinkedServer].[DB].[dbo].[Table] WHERE ID=1），看耗时是否稳定
   • 确认远程服务器的防火墙规则、网络带宽是否有变化，有时候网络波动会导致跨服务器调用延迟飙升

6. 排查应用层资源瓶颈
   不要忽略应用服务器的CPU、内存、磁盘IO：

   • 内存不足会导致频繁GC，拖慢代码执行
   • 磁盘IO过高可能影响静态资源（JS/CSS）的加载，间接导致页面加载慢

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