4

我有一个多线程进程。每个线程都受 CPU 限制（执行计算）并且还使用大量内存。根据资源监视器，该过程以 100% 的 cpu 利用率开始，但几个小时后，cpu 利用率开始缓慢下降。24 小时后，它达到 90-95% 并下降。

问题是 - 我应该寻找什么，以及我可以使用哪些最知名的方法来调试它？

附加信息：

我有足够的内存——其中大部分在任何给定时刻都没有使用。根据 perfmon - 内存不会增长（所以我认为它没有泄漏）。该代码是 .Net 和本机 c++ 的混合体，并带有一些来回编组的数据。我在几台不同的机器（具有 24 个逻辑核心的服务器）上看到了这一点。我在 perfmon 中看到的一件事 - 随着 CPU 利用率的降低，修改的页面列表字节指示器会随着时间的推移而增加。

编辑 1 使用的第三方库之一是 openfst。看起来这与该库的一些误用非常相关。具体来说，我注意到我有以下警告： warning LNK4087: CONSTANT keyword is obsolete; 使用数据

编辑 2

由于该问题已关闭且未重新打开，因此我将在问题正文中写下我的发现以及该问题是如何解决的（对不起），以供将来的用户使用。原来有一个 openfst.def 文件定义了所有 openfst FLAGS_* 符号，以供使用应用程序/dll 使用。我必须修复那些使用关键字“DATA”而不是“CONSTANT”（CONSTANT 已过时，因为它有风险 - 更多信息：https://msdn.microsoft.com/en-us/library/aa271769(v=vs. 60).aspx）。在那之后 - 没有观察到 CPU 利用率的下降。“修改的页面列表字节”指标不再上升。我怀疑它与 FLAGS 的默认值（特别是垃圾收集标志 - FLAGS_fst_default_cache_gc）有关，由于在 openfst.def 文件中误用了 CONSTANT 关键字，这些值是不确定的。

结论了解您的警告！尽可能多地消除它们！谢谢。

4

1 回答 1

0

对于像这样不明显的问题，您还应该使用一个分析器，它实际上对 CPU 中的底层硬件计数器进行采样。我熟悉的大多数分析器都使用内核提供的统计信息，而不是底层的硬件计数器。在 Windows 中尤其如此。（部分原因是遗留问题，部分原因是 Windows 希望其内核统计信息独立于硬件。PAPI API 试图解决这个问题，但仍然相对较新。）

最好的分析器之一是英特尔的 VTune。是的，我为英特尔工作，但内部 HPC 人员也使用 VTune。不幸的是，它要付出代价。如果你是学生，有折扣。如果没有，则有试用期。

您可以在 software.intel.com 找到很多优化和性能问题诊断信息。以下是优化和分析的指针。即使您不使用 x86 架构，这些技术仍然有效。

至于可能是什么问题，那么缓慢的退化是奇怪的。

  • 您多久使用一次新内存或访问旧内存？以什么速度？如果速度非常慢，您可能仍然会遇到使用资源（例如页面）变慢的情况。
  • 你的内存访问模式是什么？它会随着时间而改变吗？有多快？也许随着时间的推移，您的内存访问模式正在蔓延，从而导致更多的缓存未命中。
  • 也许你对问题空间的划分是这样的，你已经进入了一个新的计算域并且没有真正的病理学。
  • 查看是否有在较长时间间隔内发生的定期维护活动，尽管这会导致定期降级，比如每 24 小时一次。这听起来不像您的情况，因为您正在经历的是逐渐退化。

如果您使用的是 x86 架构，请考虑在英特尔论坛中提交问题（例如“英特尔® 集群和 HPC 技术”和“软件调优、性能优化和平台监控”）。

让我们知道您最终会发现什么。

于 2015-11-30T20:50:14.827 回答