Windows 上多线程 Java 应用程序的 CPU 使用率过低

Question

我正在开发一个 Java 应用程序，用于解决一类数值优化问题——更准确地说是大规模线性规划问题。单个问题可以拆分为可以并行解决的较小子问题。由于子问题比 CPU 内核多，因此我使用 ExecutorService 并将每个子问题定义为可提交给 ExecutorService 的 Callable。解决子问题需要调用本机库——在这种情况下是线性规划求解器。

问题

我可以在 Unix 和具有多达 44 个物理内核和多达 256g 内存的 Windows 系统上运行该应用程序，但对于大型问题，Windows 上的计算时间比 Linux 上高一个数量级。 Windows 不仅需要更多的内存，而且随着时间的推移，CPU 利用率从开始时的 25% 下降到几个小时后的 5%。下面是 Windows 中任务管理器的截图：

观察

• 整体问题的大型实例的解决时间从数小时到数天不等，最多消耗 32g 内存（在 Unix 上）。子问题的求解时间在毫秒范围内。
• 我不会在只需几分钟即可解决的小问题上遇到此问题。
• Linux 使用开箱即用的两个套接字，而 Windows 要求我在 BIOS 中显式激活内存交错，以便应用程序利用两个内核。不过，无论我是否这样做，都不会影响整体 CPU 利用率随着时间的推移而下降。
• 当我查看 VisualVM 中的线程时，所有池线程都在运行，没有一个处于等待状态。
• 根据 VisualVM，90% 的 CPU 时间花在原生函数调用上（解决小型线性程序）
• 垃圾收集不是问题，因为应用程序不会创建和取消引用很多对象。此外，大多数内存似乎是在堆外分配的。对于最大的实例，Linux 上 4g 的堆就足够了，Windows 上 8g 就足够了。

我的尝试

• 各种 JVM 参数、高 XMS、高元空间、UseNUMA 标志、其他 GC。
• 不同的 JVM（热点 8、9、10、11）。
• 不同线性规划求解器（CLP、Xpress、Cplex、Gurobi）的不同本地库。

问题

• 大量使用本机调用的大型多线程 Java 应用程序导致 Linux 和 Windows 之间的性能差异是什么原因？
• 我可以在实现中进行哪些更改以帮助 Windows，例如，我是否应该避免使用接收数千个 Callables 的 ExecutorService 并改为执行哪些操作？

Answer 1

对于 Windows，每个进程的线程数受进程地址空间的限制（另请参阅 Mark Russinovich - Pushing the Limits of Windows: Processes and Threads）。认为这会在接近极限时产生副作用（上下文切换速度减慢、碎片化......）。对于 Windows，我会尝试将工作负载分配给一组进程。对于我多年前遇到的类似问题，我实现了一个 Java 库来更方便地执行此操作（Java 8），如果您喜欢，请查看：Library to spawn tasks in an external process。

Answer 2

听起来windows正在缓存一些内存到页面文件，在它没有被触及一段时间后，这就是为什么CPU受到磁盘速度的瓶颈

您可以使用进程资源管理器验证它并检查缓存了多少内存

Answer 3

我认为这种性能差异是由于操作系统如何实现的。管理线程。 JVM 隐藏所有操作系统差异。您可以在许多网站上了解它，例如this。但这并不意味着差异消失了。

我想你在 Java 8+ JVM 上运行。由于这个事实，我建议你尝试使用流和函数式编程特性。当您有许多小的独立问题并且希望轻松地从顺序执行切换到并行执行时，函数式编程非常有用。好消息是您不必定义策略来确定您必须管理多少线程（例如使用 ExecutorService）。举个例子（取自here）：

package com.mkyong.java8;

import java.util.ArrayList;
import java.util.List;
import java.util.stream.IntStream;
import java.util.stream.Stream;

public class ParallelExample4 {

    public static void main(String[] args) {

        long count = Stream.iterate(0, n -> n + 1)
                .limit(1_000_000)
                //.parallel()   with this 23s, without this 1m 10s
                .filter(ParallelExample4::isPrime)
                .peek(x -> System.out.format("%s\t", x))
                .count();

        System.out.println("\nTotal: " + count);

    }

    public static boolean isPrime(int number) {
        if (number <= 1) return false;
        return !IntStream.rangeClosed(2, number / 2).anyMatch(i -> number % i == 0);
    }

}

结果：

对于普通流，需要 1 分 10 秒。对于并行 流，需要 23 秒。 P.S 使用 i7-7700、16G RAM 测试， 窗口 10

所以，我建议你阅读 Java 中的函数编程、流、lambda 函数，并尝试用你的代码实现少量测试（适应在这种新环境中工作）。

Answer 4

请您发布系统统计信息吗？如果这是唯一可用的工具，任务管理器足以提供一些线索。它可以轻松判断您的任务是否正在等待 IO - 根据您的描述，这听起来像是罪魁祸首。这可能是由于某些内存管理问题，或者库可能会将一些临时数据写入磁盘等。

当您说 25% 的 CPU 利用率时，您的意思是只有几个内核同时忙于工作吗？ （可能是所有内核不时工作，但不是同时工作。）您会检查系统中真正创建了多少线程（或进程）吗？数字总是大于核心数吗？

如果有足够多的线程，它们中的许多是空闲等待什么吗？如果为真，您可以尝试中断（或附加调试器）以查看它们在等待什么。