我在使用.Net服务时遇到了一个非常奇怪的问题。
我开发了一个多线程x64 Windows服务。
我在具有8个内核的x64服务器中测试了此服务。表现很棒！
现在我将服务移至生产服务器（x64 - 32核心）。在测试过程中，我发现性能至少比测试服务器差10倍。
我已经检查了很多性能计数器试图找到这种不良性能的原因，但我找不到一点。
可能是GC问题吗？你遇到过这样的问题吗？
提前谢谢！ 亚历山大
答案 0 :(得分：9)
这是人们通常不知道的常见问题，因为很少有人在多CPU机器上有经验。
基本问题是争论。
随着CPU数量的增加，所有共享数据结构中的争用都会增加。对于低CPU计数，争用率很低，而且您拥有多个CPU可以提高性能。随着CPU数量变得越来越大，争用开始淹没您的性能改进;随着CPU数量变大，争用实际上开始将性能降低到低于较低CPU数量的性能。
您基本上面临可扩展性问题的一个方面。
我不确定这个问题在哪里;在您的数据结构中，或在操作系统数据结构中。前者可以解决 - 无锁数据结构是一种优秀的，高度可扩展的方法。后者很难，因为它本质上要求避免某些操作系统功能。
答案 1 :(得分：2)
有太多变量可以解释为什么一台机器比另一台机器慢。 32核心机器通常更专业，其中八核可能只是一个双proc四核机器。是否有vm或其他东西在同一时间运行？通常使用那么多内核，IO带宽成为限制因素（即使cpu仍有足够的带宽）。
首先，您应该在代码中添加大量计时器（或分析或其他），以确定代码的哪一部分占用的时间最多。
性能问题101：什么是瓶颈（代码中的位置和子系统（内存，磁盘，CPU））
答案 2 :(得分：1)
这里有很多因素：
等
答案 3 :(得分：0)
是否可以归结为内存或磁盘的差异？如果存在瓶颈，则无法获得额外处理能力的值。如果没有关于应用程序/配置的更多详细信息，无法确定。
答案 4 :(得分：0)
由于许多线程同时运行，因此您必须非常小心地解决线程相互争用以访问数据的问题。阅读Non-blocking synchronization。
答案 5 :(得分：0)
您使用了多少个主题？使用许多线程池线程可能会导致线程不足，这会使您的程序变慢。
一些文章： http://www2.sys-con.com/ITSG/virtualcd/Dotnet/archives/0112/gomez/index.html http://codesith.blogspot.com/2007/03/thread-starvation-in-shared-thread-pool.html
（在其中搜索线程饥饿）
您可以使用.net分析器查找瓶颈，这里有一个很好的免费： http://www.eqatec.com/tools/profiler
答案 6 :(得分：0)
我同意Blank，这可能是某种形式的争论。不幸的是，很难追查到这一点。它可以在您的应用程序代码，框架，操作系统或其某种组合中。您的应用程序代码是最可能的罪魁祸首，因为Microsoft已经花费了大量精力在32P机箱上进行CLR和操作系统扩展。
争论可能出现在某些热锁中，但可能是某些处理器缓存行在CPU之间来回晃动。
你的指标10倍更差？吞吐量是多少？
您是否尝试使用较少的CPU启动32-proc盒？使用boot.ini或BCDedit中的/NUMPROC选项。
您是否实现了100％的CPU利用率？你的上下文切换率是多少？这与8P盒子相比如何？