诊断应用性能下降与内存占用问题：疑似WCF或MongoDB C#驱动导致？

听起来你遇到的这个偶发问题确实棘手——没有明显内存泄漏、CPU表现正常，断开客户端10分钟就能自动恢复，大概率是资源持有的临时堆积或者会话/连接层面的异常阻塞。结合你的架构细节，我给你分模块梳理排查方向：

WCF服务端排查重点 #

你的服务采用PerSession模式，同时存在双工和单调用两种实现，结合会话数配置，先聚焦这些点：

• 会话堆积与超时匹配问题：你的receiveTimeout刚好是10分钟，和恢复时间完全吻合。虽然你严格遵循了代理的Create/Close/Abort流程，但要注意：
  • 双工服务的会话生命周期依赖客户端心跳，如果客户端异常崩溃，服务端可能要等到超时才会回收会话资源。可以用Performance Monitor（PerfMon）监控WCF计数器：ServiceModelService\Current Sessions、ServiceModelService\Sessions Created/sec，看异常发生时会话数是否远超实际在线的100-120个用户。
  • 检查双工回调通道的状态：有没有客户端断开后，服务端还持有回调通道引用的情况？比如未正确处理CommunicationObjectFaulted事件，导致资源无法及时释放。
• 绑定配置的隐藏风险：你设置的maxReceivedMessageSize和maxBufferSize高达800MB，如果某个客户端发送了超大消息，可能会导致服务端内存临时暴涨。可以监控Process\Private Bytes和ServiceModelOperation\Bytes Received/sec，看异常时有没有大流量突增。
• ConcurrencyMode的线程安全问题：单调用服务用了ConcurrencyMode.Multiple+PerSession，这种模式下必须确保服务类是线程安全的。如果存在共享状态（比如静态变量、未加锁的实例变量），高并发下可能出现资源争用，导致请求排队、内存里堆积大量待处理消息。

MongoDB驱动排查方向 #

虽然连接池使用率不高，但仍有几个值得验证的点：

• 连接池的隐性阻塞：即使serverStatus显示只用了20个连接，也要确认是否存在操作未正确释放连接的情况（比如异步操作未await、异常时未关闭游标）。可以监控MongoDB驱动自带的计数器：MongoDB Driver\Connection Pool Checkouts、MongoDB Driver\Connection Pool Waits，看异常时有没有等待连接的请求堆积。
• 慢查询的连锁反应：每小时10次、单次不足5秒的慢查询看似不多，但如果刚好集中在业务高峰，可能导致服务端线程被阻塞，进而引发WCF请求堆积、内存暴涨。可以开启MongoDB的profiling级别2（记录所有操作），异常发生后导出这段时间的profile日志，排查是否有批量慢查询或异常命令（比如大文档查询、复杂聚合）。
• 副本集同步延迟：虽然OpLog时长足够，但异常发生时要检查副本集从节点的同步延迟。如果服务端读请求指向从节点，延迟会导致读操作变慢，进而引发请求堆积。可以用rs.status()查看同步状态，或监控MongoDB\Replica Set Sync Delay计数器。

通用诊断工具搭建 #

提前配置好这些工具，能帮你精准抓取异常现场：

• PerfMon实时监控：提前添加以下计数器，异常发生时导出数据：
  • WCF相关：ServiceModelService\*（会话、调用、消息计数）、ServiceModelOperation\*（延迟、字节数）
  • 系统资源：Process\Private Bytes、Process\Working Set、Processor\% Processor Time
  • MongoDB驱动：先运行驱动安装目录下的mongodbregistercounters.exe注册计数器，再监控MongoDB Driver\*系列指标
• 内存转储分析：在内存暴涨但未恢复时，用Task Manager或Procdump抓取服务端进程的.dmp文件，然后用WinDbg或Visual Studio分析：
  • 查看托管堆的对象分布，确认是否有大量WCF消息、MongoDB游标/连接对象堆积
  • 检查线程栈，看是否有大量线程卡在WCF调用或MongoDB操作上
• WCF跟踪日志：开启详细跟踪，记录所有消息和服务事件。异常发生后用SvcTraceViewer.exe分析日志，排查异常会话、消息阻塞情况。配置示例：

  <system.diagnostics>
    <sources>
      <source name="System.ServiceModel" switchValue="Information,ActivityTracing" propagateActivity="true">
        <listeners>
          <add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData="c:\logs\wcf_trace.svclog" />
        </listeners>
      </source>
      <source name="System.ServiceModel.MessageLogging">
        <listeners>
          <add name="messageListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData="c:\logs\wcf_messages.svclog" />
        </listeners>
      </source>
    </sources>
  </system.diagnostics>
  

排查优先级建议 #

先从PerfMon监控入手，快速定位会话、内存、连接的异常波动——这是成本最低、见效最快的方向。如果发现会话数异常，重点排查WCF会话回收逻辑；如果MongoDB连接等待或慢查询批量出现，就往驱动和数据库方向深挖。内存转储是终极手段，能直接看到堆积的对象和阻塞的线程，帮你锁定根源。

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