【问题标题】:Single / multiple JVM on Single Machine with single / multiple core单/多核单机上的单/多JVM
【发布时间】:2017-11-06 21:18:16
【问题描述】:

我有几个问题,我在网上搜索了以下问题,但更加困惑。

  1. 我有 java 应用程序在单机上运行,​​单机 JVM,20 核机,20 GB 内存,20 个 java 线程。 (单机,单JVM,20核,20GB内存,20个java线程)
  2. 我有 java 应用程序在单台机器上运行,有 20 个 JVM,20 个核心机器,每个 JVM 有 1 GB ram,每个进程有 1 个 JAVA 线程。 (单机,20个JVM,20个核心,20GB内存,20个java线程)

从上面的第1点和第2点来看,哪个更好,为什么

  • 应用性能
  • 机器的 CPU 利用率
  • 如果即使增加线程数也没有完全消耗 CPU,那么在应用程序或机器中做什么才能利用更多 CPU。
  • 在这种情况下,上下文切换会更多。

在上面的1和2点中,假设每个线程需要10ms来完成任务,那么在情况1和2中完成所有任务需要多少时间。请解释一下。

我搜索并听说过有关 CPU 利用率的 CPU 密集型和 I/O 密集型应用程序。你能解释一下吗,因为我很困惑。

通常建议线程数等于内核数。如果我的线程数比内核数多,那会产生什么影响。请解释一下。

【问题讨论】:

    标签: java performance parallel-processing jvm


    【解决方案1】:

    你有很多不同的变量在起作用,不会有一个简单的答案。我将在下面添加一些细节,但 tl;dr 版本将“为您的场景运行一些测试,看看什么效果最好”。

    每个 CPU 是否应该有一个线程取决于您的工作负载。正如您显然已经发现的那样,如果您的线程是 cpu 密集型的(也就是说,大部分时间它都在积极使用 cpu),那么一个线程将接近于完全利用一个 cpu。但是,在许多实际情况下,您的线程可能必须执行其他操作(例如等待 I/O),在这种情况下,它不会充分利用 cpu(这意味着您可以在每个 cpu 上运行多个线程)。

    另外,在您的两种情况下,您需要考虑所有 jvm 开销。每个 jvm 都会有许多自己的线程(最值得注意的是 GC 线程)。这些会给你的 CPU 使用增加额外的开销。如果您的代码大量使用垃圾收集器(在工作时创建/丢弃大量垃圾),每个线程有单独的 jvm 可能是有益的,但您需要考虑额外的 gc 线程 cpu 使用情况。如果您的代码不会产生大量垃圾,那么使用单独的 jvm(以及许多额外的 gc 线程)可能只是在浪费资源。

    考虑到所有这些变量,以及线程的实际工作负载情况,仅凭理论是不可能找到正确答案的。使用真实世界数据测试各种场景是您找到适合您的应用程序的唯一方法(它可能最终成为中间的东西,例如 4 个 jvm,每个 5 个线程)。

    【讨论】:

    • 感谢您的回答。 1) 考虑到应用程序没有大量使用 GC,通常单机上的 1 个 JVM 更好还是单机上的多个 JVM 更好? 2)如果CPU没有完全消耗甚至增加线程数,那么在应用程序或机器中做什么以利用更多的CPU。 3)以上1点和2点,假设每个线程完成任务需要10ms,那么情况1和2完成所有任务需要多少时间。请解释一下。
    • @VJS for 1,3 我相信我已经回答了上述问题:“变量太多,无法给出有意义的答案,您必须测试您的应用程序以确定最有效的方法”。对于 2,在一个像样的分析器下运行你的代码以找到瓶颈,然后修复它们。
    • 感谢您的回复。正如您所提到的,“在一个像样的分析器下运行您的代码以找到瓶颈......”我的方法是什么?假设我在 JProfiler 下运行我的代码,为了破解它应该是什么区域或识别机制,即为什么我的应用程序没有使用更多的 CPU。我的意思是,我在我的应用程序或 Jprofiler 中看到了什么?
    • @VJS - 网上可能有各种各样的教程可以有效地使用代码分析器。通常,分析器会告诉您代码的“慢”部分在哪里。然后你让这些更快。清洗,冲洗,重复。
    • 谢谢。还有一个问题,即“一般来说,分析器会告诉你代码的“慢”部分在哪里......”如果我让这些部分变快,那么它会影响我的 CPU 利用率吗?那么,您的意思是,让您的代码快速运行会提高 CPU 利用率?
    猜你喜欢
    • 1970-01-01
    • 2012-01-25
    • 1970-01-01
    • 2013-03-22
    • 2020-10-21
    • 2011-05-15
    • 2020-06-10
    • 2013-01-29
    • 1970-01-01
    相关资源
    最近更新 更多