Oracle Linux 上的 Java 性能问题

如何解决Oracle Linux 上的 Java 性能问题

我正在运行非常“简单”的测试。

@Fork(value = 1,jvmArgs = { "--illegal-access=permit","-xms10G","-XX:+UnlockDiagnosticVMOptions","-XX:+DebugNonSafepoints","-XX:ActiveProcessorCount=7","-XX:+UseNUMA","-XX:disableIntrinsic=_currentTimeMillis,_nanoTime","-Xmx10G","-XX:+UnlockExperimentalVMOptions","-XX:ConcGCThreads=5","-XX:ParallelGCThreads=10","-XX:+UseZGC","-XX:+UsePerfData","-XX:MaxMetaspaceSize=10G","-XX:MetaspaceSize=256M"}
)
    @Benchmark
    public String generaterandom() {
        return UUID.randomUUID().toString();
    }

可能不是很简单，因为使用随机，但同样的问题是在任何其他使用 java 的测试中

在我的家庭桌面上

Intel(R) Core(TM) i7-8700 cpu @ 3.20GHz 12 Threads (hyperthreading enabled ),64 GB Ram,"Ubuntu" VERSION="20.04.2 LTS (Focal Fossa)"
Linux homepc 5.8.0-59-generic #66~20.04.1-Ubuntu SMP Thu Jun 17 11:14:10 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

7 个线程的性能：

Benchmark                                            Mode  Cnt        score       Error   Units
RulesBenchmark.generaterandom                       thrpt    5  1312295.357 ± 27853.707   ops/s

Flame Graph with AsyncProfiler Result with 7 Thread At Home

我在 Oracle Linux 上遇到问题

Linux  5.4.17-2102.201.3.el8uek.x86_64 #2 SMP Fri Apr 23 09:05:57 PDT 2021 x86_64 x86_64 x86_64 GNU/Linux
Intel(R) Xeon(R) Gold 6258R cpu @ 2.70GHz with 56 Threads(hyperthreading disabled,the same when enabled and there is 112 cpu threads ) and 1 TB RAM I have half of performance (Even increasing threads) NAME="Oracle Linux Server" VERSION="8.4"

使用 1 个线程，我的表现非常出色：

Benchmark                                            Mode  Cnt        score      Error   Units
RulesBenchmark.generaterandom                       thrpt    5  2377471.113 ± 8049.532   ops/s

Flame Graph with AsyncProfiler Result 1 Thread

但是有 7 个线程

Benchmark                                            Mode  Cnt       score       Error   Units


RulesBenchmark.generaterandom                       thrpt    5  688612.296 ± 70895.058   ops/s

Flame Graph with AsyncProfiler Result 7 Thread

可能是 NUMA 的问题，因为有 2 个 Sockets，而系统只配置了 1 个 NUMA 节点 numactl --hardware

available: 1 nodes (0)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55
node 0 size: 1030835 MB
node 0 free: 1011029 MB
node distances:
node   0 
  0:  10

但是在使用以下方法禁用一些 cpu 线程后：

for i in {12..55}
do
 # your-unix-command-here
  echo '0'| sudo tee /sys/devices/system/cpu/cpu$I/Online
done

性能略有改善，但不大。

这只是非常“简单”的测试。在使用真实代码进行复杂测试时，它甚至值得，它在 .annobin___pthread_cond_signal.start

上花费了大量时间

我还在家用台式机上部署了具有相同版本的 Oracle Linux 和内核版本的 vagrant 映像，并使用 10 个 cpu 线程运行它，性能几乎与台式机相同（约 1M 操作/秒） .所以这不是关于操作系统或内核，而是一些配置

在多个 jdk 版本和供应商（jdk 11 及更高版本）上进行了测试。使用 YUM 发行版中的 OpenJDK 11 时，性能非常，但不显着。

你能提出一些建议吗提前致谢

解决方法

本质上，您的基准测试测试了 class MainWindow(QMainWindow): def __init__(self): super(MainWindow,self).__init__() loadUi('browse.ui',self) self.listWidget.clicked.connect(self.item_clicked) def item_clicked(self): item = QtWidgets.QListWidgetItem() item = self.listWidget.currentItem() self.chosenitem_list.addItem(item) 的吞吐量。默认实现是 synchronized（更准确地说，默认实现混合了输入表单 SecureRandom 和上述提供程序）。

矛盾的是，更多的线程会导致更多的争用，从而降低整体性能，因为算法的主要部分无论如何都处于全局锁定之下。 Async-profiler 确实表明瓶颈是 Java 监视器上的同步：/dev/urandom、__lll_unlock_wake、__pthread_cond_wait - 都来自该同步。

争用开销肯定取决于硬件、固件和操作系统配置。与其试图减少这种开销（这可能很难，因为，你知道，总有一天会出现另一个安全补丁，例如，会使系统调用慢 2 倍），我建议在第一个中摆脱争用地点。

这可以通过安装不同的非阻塞 __pthread_cond_signal 提供程序来实现，如 this answer 所示。我不会就特定的 SecureRandom 给出建议，因为这取决于您的具体要求（吞吐量/可扩展性/安全性）。只是提到一个实现可以基于

rdrand
OpenSSL
原始 SecureRandomSpi 访问权限等