【问题标题】:How to detect multicore scalability/contention issues如何检测多核可扩展性/争用问题
【发布时间】:2017-10-09 14:13:03
【问题描述】:

我在多核系统上面临可扩展性问题。我的应用程序在 4 个物理核心机器上并行处理科学数据,8 个逻辑核心激活了超线程。我们启动了 8 个 JVM,每个逻辑核心一个(我们最终可能会切换到一个 JVM 以避免 JVM 的开销)

问题在于,最多 4 个核心的可扩展性几乎是线性的,但是通过增加 4 个“逻辑核心”,我们几乎无法获得 10-20% 的性能。

我通过分析应用程序来分析线程行为,我没有看到任何锁或等待过多的线程。我还检查了 pidstat 并且我没有看到例如过多的上下文切换开销。更准确地说,Java 进程几乎没有上下文切换。 CPU 使用率非常高,几乎达到 100%,这似乎也还可以。

我的问题是如何在超过物理内核数量后检测和分析这种不良可扩展性的原因。我可以使用哪些工具和方法来检测争用在哪里,我应该在哪里查看,我可以在不改变应用程序架构的情况下以某种方式修复它(例如每台机器切换到一个 JVM)

谢谢

【问题讨论】:

    标签: java scalability multicore hyperthreading


    【解决方案1】:

    请注意,超线程不会使单个内核的容量翻倍。事实上,当超线程开启时,有些任务的性能会更差。

    收益将在很大程度上取决于工作的性质 - 更多的管道停顿将意味着更多的机会安排另一个进程来代替停顿的进程。

    举个例子:完全随机访问内存在超线程性能提升方面会比在同一缓存行中的非常快速的 CPU 密集型计算产生更多。

    以下是两个硬件线程共享的东西,因此任何都会产生限制任何收益的争用:

    • 缓存
    • 分支预测资源
    • 指令获取和解码
    • 执行单元(整数和浮点)

    另一个观察结果是操作系统必须支持 SMT/HT,否则它将无法将任何内容安排到额外的内核中,或者会安排错误的任务。

    当操作系统支持时,仍然有可能在文件句柄或网络套接字等方面发生操作系统争用。工作的性质越“令人尴尬的可并行化”,就越有机会限制这种争论。但是,如果您的工作涉及读取和/或写入相同的系统资源,您将获得较少的收益。

    一旦您将所有这些任务引入 1 个 JVM,您的并行度将是:

    int cores = Runtime.getRuntime().availableProcessors();
    

    【讨论】:

    • 感谢您的回答,它正在澄清问题空间。我会看看缓存未命中,并且我会尝试仅使用物理内核运行以获得一个想法。
    猜你喜欢
    • 1970-01-01
    • 2018-06-19
    • 2014-02-10
    • 2023-01-17
    • 2015-04-26
    • 2012-02-05
    • 1970-01-01
    • 1970-01-01
    • 2012-04-23
    相关资源
    最近更新 更多