☰

如何诊断 Java 进程在内核空间中正在做什么

tag-icon • tag-icon linux java kernel high-load
如何诊断 Java 进程在内核空间中正在做什么

我们的 Hadoop 集群上的一个 Spark (Java) 应用程序存在问题。当此工作负载在我们的集群内核空间中的 3 台机器上调度时，CPU 使用率会变得非常高。来自 sar 的示例记录：

09:35:52        CPU     %user     %nice   %system   %iowait    %steal     %idle
[...]
09:36:28        all     56.62      0.00     33.89      0.00      0.00      9.50
09:36:29        all     55.84      0.00     32.67      0.00      0.00     11.49
09:36:31        all     53.18      0.00     34.67      0.10      0.00     12.05
09:36:32        all     55.86      0.00     32.37      0.00      0.00     11.77
09:36:34        all     56.67      0.00     32.43      0.00      0.00     10.90
09:36:36        all     53.45      0.00     35.03      0.11      0.00     11.41
09:36:37        all     60.71      0.00     25.82      0.00      0.00     13.47
09:36:39        all     56.91      0.00     26.84      0.00      0.00     16.25

到目前为止我设法排除：

  • cgroup 拥塞 - 我们以前也遇到过
  • 散热问题 - 在“事件”期间我们没有看到 CPU 频率下降。
  • 由于 iowait 很低，所以看起来不像是有什么在等待 IO。
  • 机器电力不足 —— 在这种情况下，我们应该看到频率下降，而且肯定不会出现高内核空间 CPU。

我尝试运行 perf 并查看火焰图，但没有发现任何有趣的东西（除了“它是 java”）。但是我在这方面缺乏经验，所以也许我错过了图表上的一些东西： Perf 火焰图

在事件发生期间，我们在 dmesg 中没有看到任何与常规不同的内容。我们要求 HP 检查这些机器的硬件，他们声称一切正常。我们要求 RedHat 和我们的内部 Linux 团队进行调查，他们基本上说“这是您的应用程序导致的问题，请不要再打扰我们了”。该问题仅出现在整个集群中的 3 个特定节点上（当负载落在其他节点上时，它运行良好）。

我们已经不知道该如何检查到底发生了什么。你能帮我们吗？

我们的配置如下：

  • Cloudera CDH 6.1.1

  • 集群中有 10 台机器（外加 4 个管理节点），只有 3 台出现问题

  • 操作系统：RHEL 6.10 Santiago 2.6.32-754.25.1.el6.x86_64

  • 机器：HP ProLiant SL4540 Gen8（一个 4U 机箱中有 3 台机器，出现问题的机器都在同一个机箱里，但 HP 声称硬件不是问题）。

答案1

我们已经不知道该如何检查到底发生了什么。你能帮我们吗？

与内核交互需要系统调用，因此请尝试附加strace(1)进入你的集群进程，看看发生了什么。

可能从类似的东西开始

$ strace -cp $(cat /path/to/pid_file.pid)

显示您的进程的系统调用摘要，并从那里开始跟踪。

答案2

首先，不健康和健康机器之间的性能差异是什么？ 有 2 倍或更多的差异吗？ 你知道吗？

您在其他节点上看到的利用率是多少？

“这是你的应用程序造成的问题，请不要再打扰我们”

您有证据表明您的应用程序导致了问题吗？您可以检查pidstat输出以查看来自“java”和其他内容的比例。

然后我会检查受影响节点上的上下文切换数量，并将其与健康节点进行比较。您可以使用perf stat -e cs -a -I 1000它。

虽然它可能不是 100% 适用于你的情况，但有一个很好的例子，它涉及大量上下文切换的问题Brendan Gregg 在 LISA2019 上的 Linux 系统性能演讲- 前8分钟左右。

正如 @mforsetti 所建议的，你也可以使用它，strace但在生产服务器上运行时要非常小心 - 它可能会使你的应用程序速度降低 100 倍（http://www.brendangregg.com/blog/2014-05-11/strace-wow-much-syscall.html）。作为有限的strace替代方案，可以使用perf trace。

相关内容