C#多进程-多线程服务和windows调度器

Posted 2023-04-13

【中文标题】C#多进程-多线程服务和windows调度器

【英文标题】：C# multiprocess-multithread service and windows scheduler

【发布时间】：2017-03-24 05:44:13

【问题描述】：

我开发了一个 Windows 服务，很快就可以管理数千个远程设备。 目前它由两个进程组成，每个进程都有数百个线程（我们可以讨论减少线程数量的机会，但这不是重点），而且一切都很好。 现在我试图在一个进程中加入所有线程以简化线程之间的数据交换，但是现在所有线程的运行速度都变慢了（在某些情况下，某些线程的运行频率似乎要低得多）。 所以我的问题是：与多进程/多线程应用程序相比，预计 Windows 调度程序在单进程/多线程应用程序上的工作方式不同？

简单的例子： - 单核 CPU - 2 个线程（A 和 B） - 线程 A 正在执行一个很长的任务，而线程 B 正在休眠 - 现在是唤醒线程 B 的时候了，但线程 A 仍在运行

我的猜想： - 在单进程/多线程上，调度程序强制线程 B 休眠并延迟其唤醒 - 在多进程/多线程上，如果 A 属于进程 1，B 属于进程 2，调度程序会在预期时唤醒线程 B

可能吗？ 有什么建议可以在一个进程中加入所有线程而不会出现问题吗？

对不起，我的英语不好。

编辑 按照 Luaan 的建议，我正在分析应用程序以检查 GC 行为。这是我在 45 秒的时间段上看到的： 一些问题： - 为什么是 13.000.000 毫秒？ - 为什么在这里提到 sleep？

编辑 2 最后我解决了我的性能问题：正如我所说，我在我的服务中使用了数百个线程。我已经重写了代码的某些部分，以便将旧线程分组到几个主线程中，现在我正在使用 8 个主工作线程来完成大部分工作（包括辅助线程在内总共大约 50 个线程）......现在神奇的是服务使用像一半的 cpu 运行。 也许这个问题也与 GC 活动有关，但我认为大多数问题是由于我的线程的上下文切换开销。

编辑 3 随着一些小的性能问题继续存在，我使用 PerformanceCounter 对象检查了 GC 负载，你是对的：当 GC 使用大约 99% 的 cpu 时间时，我的线程挂起。我该如何解决？现在我正在尝试将 GC 设置为服务器模式。

【问题讨论】：

您的问题中没有足够的信息来提供很大帮助。你在搞乱线程/进程的优先级吗？ “服务”之一是 GUI 应用程序吗？你是在做阻塞 I/O 还是非阻塞 I/O？您在线程之间使用什么同步？什么信号？ GC 是如何参与其中的（请记住，加入流程意味着加入他们的 GC）？并发分析器告诉你什么？此外，单核 CPU 在多线程中的表现非常不同 - Windows 试图最小化上下文切换开销，因此它不像在多核上那样积极地调度。

我尝试提供更多信息：我没有管理线程优先级；没有 GUI，只是一个 Windows 服务；我在很多线程上对 SQL Server 进行阻塞操作；我不是在管理线程同步，每个线程都在做自己的工作，我在线程之间异步交换数据；我并没有以某种方式强迫 GC，但我确实通过分析器看到 GC 做了“很多”工作。最后，真正的服务器不是单核，而是有 4 个核。谢谢。

基本上，对 SQL Server 执行 I/O 的线程似乎正在阻塞执行与设备通信的线程。如果线程在不同的进程上，则不会发生这种情况。

好吧，如果 GC 在您的进程中得到大量工作，那么很可能是导致速度变慢的原因。两个进程意味着两个独立的托管内存空间，它们有自己的 GC。特别是，如果其中一个进程占用大量内存，加入它们会使另一个进程变慢。当您分析服务时，似乎 GC 暂停可能是在正确的范围内解释减速？

感谢您的提示。我将再次使用探查器进行检查。抱歉，但我无法理解您的问题（“当您分析服务时，似乎 GC 暂停可能是在正确的范围内解释减速？”）。我到底需要检查什么？

【参考方案1】：

首先，CPU 内核和线程无关。内核决定如何在逻辑 CPU 之间划分线程。逻辑 CPU 越低，上下文切换就越多，总体上会减慢进程，但它仍然是多线程的。

如果您想与其他线程交谈，那么通常的过程是使用主应用程序线程订阅的事件来执行此操作。然后，您可以决定如何处理这些信息。

您不应该关心内核如何在逻辑 CPU 上划分线程，因为它会自动执行此操作，除非您专门使用处理器关联掩码。

【讨论】：

嗨，谢谢，我同意你的看法。但是你对我的问题有什么看法（“发生的事情是现在所有线程都运行得更慢了”）？