您好 我有一个非常不寻常的问题因为我认为在我的情况下工作流运行时没有使用足够的CPU功率。情景如下:
我观察到CPU(8核心)利用率低,不超过15%。我可以补充一点,我有一个负责工作流逻辑的独立流程,并且我与WCF进行通信。
答案 0 :(得分:2)
你有记录,你认为这不是问题,但你不知道。有许多数据库操作。那些需要阻止I / O.拥有更多内核只会在不同线程无阻碍运行时提供帮助。
我讨厌听起来像是一张卡住的唱片,总是小跑同样的答案,但你猜测问题是什么,而你也要求其他人猜测。人们非常愿意猜测,但猜测不起作用。您需要找出正在发生的事情。
要了解发生了什么,我使用的方法是让它在调试器下运行。 (通过下到一个核心简化问题。)然后暂停整个事情,查看每个活动线程,并找出它正在等待的内容。如果由于某种原因它正在等待一些CPU限制功能完成,那就好了 - 记下它。如果它正在等待某些日志记录完成,请记下。如果它正在等待数据库查询完成,请记下它。如果它正在等待某个其他线程的互斥锁,请记下它。
为每个线程执行此操作,并执行多次。然后,你真的可以说你知道它在做什么。当你知道它在等什么以及为什么时,你会非常清楚如何改进它。这是this technique的变体。
答案 1 :(得分:0)
你在工作项目中做什么?
如果您有任何类型的跨线程同步(关键部分等),那么这可能会导致您花时间停止线程等待资源变为空闲。
例如,如果您正在进行任何类型的文件访问,那么您将花费大量时间阻止等待负载完成,这将使您的线程在很多时候处于空闲状态。您可能会在问题上抛出更多线程,但最终会产生更多磁盘请求,资源争用将成为更多问题。
这有几个潜在的想法但我真的需要知道你在做什么才能更有用......
编辑:回答你的意见......
1)OK
2)由于切换开销,你的表现非常糟糕。事实上,在8核机器上运行20-25个线程也可能是一个糟糕的计划,因为如果你让它们高速运行,那么它们将花时间窃取彼此的运行时间和常规上下文切换(软件线程切换)非常昂贵。它们可能不会像等待你的代码那样昂贵
3)记录?您是否只是将它们提交给异步队列,当它有机会时将它们分配给磁盘,或者它们是否是同步文件写入?如果它们是aysnchronous,你能保证在你必须等待之前没有可以排队的最大请求数吗?如果你不得不等待多少线程最终争夺刚开放的空间?那里有很多ifs
4)如果2个线程同时对数据库进行类似的调用,即使在最佳数据库上也可能阻塞数据库操作。一个好的数据库旨在限制这一点,但很可能会发生至少一些冲突。
可以说你会想要一个好的线程分析器,看看时间真正丢失的地方。如果做不到这一点,你将不得不忍受性能或以不同的方式解决问题......
答案 2 :(得分:0)
WF3的表现有点偏慢。如果您使用的是.NET 4,那么您将获得更好的性能转移到WF4。请注意,重写是因为WF4是完全不同的产品。
至于WF3。有白皮书here可以为您提供大量信息,以改善标准设置。查找增加DefaultWorkflowSchedulerService使用的线程数或切换到ManualWorkflowSchedulerService并禁用默认启用的性能计数器等事项。