WCF“自托管”应用程序变得无响应答案

【问题标题】：WCF "Self-Hosted" application becomes unresponsiveWCF“自托管”应用程序变得无响应
【发布时间】：2013-05-31 14:15:28
【问题描述】：

我们有一个 C# (.Net 4.0) 控制台应用程序，它“自托管”两个 WCF 服务：一个使用 WSHttpBinding，另一个使用 BasicHttpBinding。

连接到这些服务后，我们有两个独立的客户端应用程序：一个使用 BasicHttpBinding 的基于 Silverlight 的服务，另一个使用 WSHttpBinding 的控制台应用程序。

WCF 服务应用程序通常有大约 30 个用户通过 Silverlight 客户端进行连接，另外还有几个来自控制台应用程序客户端的连接。无论如何，它都不是“平淡无奇”。每个客户端最多每 5 秒查询一次 WCF 服务。

问题是：服务应用程序间歇性地无响应。尽管服务器本身继续运行（它继续写入日志文件），但所有 WCF 活动（在 ServiceHosts 上）似乎都“占用”了。不处理新请求（尽管接受 TCP 连接）。此外，应用程序消耗的线程数开始急剧增加，大约每秒一个新线程。代码本身对Threads 或ThreadPools 没有任何作用，尽管它偶尔会在几百毫秒内发出Thread.Sleep。

令人沮丧的是问题的间歇性：代码经常运行数小时，甚至数天而没有任何问题。然后，在没有明显原因的情况下，它突然变得无响应并且线程数开始增加。

我尝试过模拟用户活动 - 连接和断开客户端，用请求“淹没”服务 - 但我无法重现故障。

以防万一问题是 WCF 限制，我添加了以下代码：

 ServiceThrottlingBehavior throttlingBehavior = new System.ServiceModel.Description.ServiceThrottlingBehavior
                                                           {
                                                               MaxConcurrentCalls = 512,
                                                               MaxConcurrentInstances = 8192,
                                                               MaxConcurrentSessions = 8192
                                                           };

        host.Description.Behaviors.Add(throttlingBehavior);
        host2.Description.Behaviors.Add(throttlingBehavior);

.. 没有明显效果。

我已在代码中添加了大量日志记录，以尝试确定触发此行为的原因 - 记录对每个方法的每次调用 - 但结果未出现任何结果。我已经将所有内容包装在try...catch 块中，并将任何异常吐出到日志文件中，以查看是否有东西掉到某个地方，并以类似的方式困住了UnhandledExceptions ......但又一次，似乎没有任何问题。

上述行为是否对任何人来说都很熟悉，或者任何人都可以提出解决此问题的最佳方法吗？

编辑：按照下面 Wal 的建议，当应用程序开始出现异常行为时，我已经捕获了该应用程序的 .DMP，并查看了 VS2012 中的 Parallel Stacks 视图，我看到了：

... 和其他非常相似但线程数不同的。我不够聪明，无法准确解读这意味着什么.. 谁能建议下一步从哪里开始？

【问题讨论】：

当你在 .net4 中时，你可以使用任务管理器来转储你的进程并将该转储文件拖回 VS 并查看并行堆栈以查看发生了什么。希望这很明显，否则你可能不得不走 windbg 路线。（使用相同的转储文件）。希望问题本身很简单，例如您的客户发送的另类的东西无意中备份了您的处理队列
你在调用方法后关闭你的客户吗？可能相关johan.driessen.se/posts/…
我想您已经尝试过了，但是...您是否启用了（几乎）所有与您的流程相关的性能计数器的收集？发生这种情况时，您可以比较收集的数据（争用与线程一起上升？内存使用率比线程上升得更快？等等......）
除非您了解它们的工作原理，否则不应更改 WCF 限制的默认设置。我建议您不要覆盖它们，因为这很少有用。另外，您是否使用服务主机的默认 ConcurencyMode 和 InstanceMode 设置？欲了解更多信息，请阅读this excellent post
我的专业知识位，但这听起来像是主线程之外的某些静态资源的竞争条件。 WCF 服务肯定会继续接受连接，并继续产生新线程，这些线程永远不会返回，因为前两个线程将其锁定。除了日志文件，是否还有其他正在访问的文件？根据我的经验，即使是只读的“非独占”访问也会导致竞争条件。您是否将所有静态资源包装在 lock (lockobject) { } 块中？

标签： c# .net wcf

【解决方案1】：

服务的并发模式是什么？和instancecontextmode？p>

默认 instancecontextmode 是 per session，可能值得将其更改为 percall，这将使用更多内存但将确保每个服务实例都不会闲置（前提是客户端正确处理 http://coding.abel.nu/2012/02/using-and-disposing-of-wcf-clients/）

【讨论】：

【解决方案2】：

正如之前指出的那样，听起来您有竞争条件。您是否没有机会检查代码中某处连接的 System.ServiceModel.ICommunicationObject.State ？见MSDN article：

Checking the value of the System.ServiceModel.ICommunicationObject.State property is 
a race condition and is not recommended to determine whether to reuse or close a channel.

【讨论】：

【解决方案3】：

感谢所有评论和回答的人；您的建议和意见真的很有帮助 - 尤其是确认这似乎不是我错过的小事。

但是，有点令人沮丧的是，问题似乎已经消失了。这是我所做的更改：

应用程序定期写入控制台（我的“WriteToLog”方法有Console.WriteLine 以及附加到文件；这纯粹是为了我自己在开发过程中的方便）。该应用程序还使用 FireDaemon 作为服务运行，出于某种原因，我们开始在 conhost.exe 上看到高 CPU 时间。所以为了解决这个问题，我注释掉了Console.WriteLine。
由于 CPU 较高，我们还通过向其添加更多内核来提高运行代码的虚拟机的性能。

因此，应用程序现在在 CPU 使用率方面“安静”得多。正如其他人所提到的，几乎可以肯定代码中的某个地方存在“竞争条件”，但是通过使底层机器更快并且代码更高效，似乎我已经减少了竞争条件发生的机会。当然，每天至少发生一次的问题在近一周内都没有发生过。

为了确定，我已经检查了代码并确保每个共享对象都包装在 Lock() 中，其中有可能被另一个线程修改 - 即使我没有做任何显式线程，我假设 WCF 机制会自动执行此操作，并且传入请求可能会尝试修改对象，而其他东西正在咀嚼它。如果发生这种情况，我会预料到某种并发异常？

再次感谢您的帮助，希望代码不会在我单击Post Your Answer 按钮后发生故障：/

【讨论】：

【解决方案4】：

可能是与 WCF 无关的线程问题 - 正如之前的帖子中提到的，锁定语句可能是可疑的 - 您的应用程序（WCF 部分与否）可能已启动线程，由于以下原因无法退出锁定问题。

另一方面，它可能是 WCF，您的 WCF 服务是否受到很多点击？试试油门。 http://msdn.microsoft.com/en-us/library/system.servicemodel.description.servicethrottlingbehavior.maxconcurrentinstances.aspx

【讨论】：