Parallel.ForEach 性能不佳答案

【问题标题】：Parallel.ForEach poor performanceParallel.ForEach 性能不佳
【发布时间】：2012-09-03 14:01:23
【问题描述】：

我写了一个小程序，可以将一堆文件转换为 pdf。

程序执行以下操作：

从文件夹中获取FileInfo 对象数组（10'000 个文档）
对于每个FileInfo
- 使用FileInfo.CopyTo() 创建备份副本，
- 使用一些 Aspose 库将文档转换为 PDF
- 转换后，将 PDF 复制到新的目标位置
- 在 foreach 内部，一个事件被引发并由 WinForm UI 处理以显示一些进度

根据文档的大小，文档的转换可能需要 0-3 秒。我认为这将是Parallel.ForEach 的完美候选，所以我修改了程序。

但是，转换需要 1 小时而不是传统的 foreach 1.5 小时 Parallel.Foreach（我试过的服务器有 2 x Intel Xeon Procs）。

我做错了什么或者我需要考虑什么才能获得更好的性能？

【问题讨论】：

【解决方案1】：

我建议通过查看任务管理器中的 CPU 和资源监视器中的磁盘 I/O 响应时间/队列长度和/或查看各种可用的性能计数器来检查您的操作是否受 CPU 限制或 I/O 限制。

我怀疑您的问题很可能是您现在正在同时执行多个文件副本（用于创建备份和写入转换后的文件）。与随机访问相比，硬盘的顺序访问（如果您一次只写入/读取一个文件）要快得多。

【讨论】：

【解决方案2】：

我可以考虑几个可能导致 Parallel.Foreach 变慢的问题：

它谈论的是单核，但它可以反映你的问题。

【讨论】：

@Jon: 除非他在同一个进程的多个线程中使用库，并且库需要锁（强制所有工作按顺序完成）
@BenVoigt 是的。我在想“以一种远离其他线程的方式很好地使用单线程”作为“单线程”，这是支持这种并行使用的最佳方式，而不是“多线程”，因为它, 本身使用多个线程。

【解决方案3】：

这取决于很多事情。我当然会尝试将 MaxDegreeOfParallelism 设置为 2，希望如果转换是 CPU 密集型和单线程的，那么每个内核有一个应该接近理想，但肯定会进一步试验。

但是您的方法假设转换本身并没有很好地利用多个内核。如果确实如此，并且它受 CPU 限制，那么它已经在对您尝试引入的内核进行某种并行使用，并且您可能会因此而降低整个事情的效率。

编辑：根据 svick 的评论，想法变得更加清晰。如果库不支持多线程使用，那么它不太可能在不出错的情况下走到这一步，但它对多线程的支持可能涉及大量内部锁定，当偶尔有并发调用时可能会很好，但非常昂贵如果你有长期的高并发。

【讨论】：

您认为由并行化已经并行的进程引起的更多上下文切换可能会导致 50 % 的减速？
@svick 我会说这不太可能，但第二段可以适用于它，很好地优化使用缓存，这将放大这种影响和需要锁定的内部结构，这可能更重要。
大量 IO 绑定线程（如果您的限制因素是磁盘 IO）意味着并行线程几乎只是开销，50% 似乎是很多开销，尝试使用越来越少的线程来看看这对性能有何影响。
设置 MaxDegreeofParallelism 是个好主意，但我非常怀疑双插槽 Xeon（问题中的描述并不完全清楚，但听起来就是这样）只有 2 个内核。跨度>
@BenVoigt 是的，你是对的，尽管在这个问题上，尝试低于预期的方式也可能是件好事。我认为第二种情况更有可能；它只是不能很好地并行化。