java - 是什么导致软件在更好的硬件上运行速度较慢？

Question

我有一个运行在RHEL 7.4上的Java OSGi(Apache Felix)应用程序，该应用程序以〜975个数据包/秒(长度为1038个八位字节)的速度读取多播UDP。然后，它将数据转换为XML，模拟跨边界设备，然后将其转换回UDP多播数据包。涉及多个线程，其编写方式是，如果模拟边界设备花一点时间来处理一个有效载荷，它将对其进行缓冲并在下一次发送更大的有效载荷。

通过这种集成测试方案查看数据包延迟时，两个不同的台式机比我们预期与其一起部署的相当高端的服务器要快得多。

服务器延迟5秒。硬件:双Xeon E5-2667v4 @ 3.2GHz，128G RAM，16个物理，21个逻辑内核，RAID 1 SAS SSD。

桌面A <1秒。硬件Xeon E5-1620v4 @ 3.5Ghz，64G RAM，4个物理，8个逻辑内核，500G SSD

桌面B <1秒。硬件i7-3770 @ 3.4Ghz，16G RAM，4个物理，8个逻辑内核，1TB 7200RPM驱动器。

我只提到硬盘驱动器的完整性，因为此应用程序未写入磁盘。在纸上，服务器的性能至少应与两个台式机一样快。

我淘汰的事情:

网卡。我已经对物理NIC和虚拟设备进行了测试，以防NIC之间存在显着差异。

逻辑核心数。为了排除变量，我尝试禁用16个和24个服务器逻辑核心。

Java版本。这三种方法都已经在OpenJDK和Oracle Java中进行了尝试，它们具有相同的版本(Java 1.8.0)，可以产生相同的结果。

Java标志是相同的，并且都与felix(安装目录，配置属性和要执行的jar)有关。

SELinux。我已经在所有三种模式(禁用，强制，允许)中进行了尝试。我没想到这里有什么区别，但是我现在正在抓住任何东西。

内核版本。我已经尝试过对3.10.0，4.13.0和4.15.0进行测试，结果相似。

ark.intel.com processor comparison

这是两个示例图来说明问题。此测试在4分钟10秒内将260,960个UDP数据包发送到多播地址A，并在通过应用程序对其进行处理后，将数据包发送到多播地址B。 tcpdump记录了两者的时间戳，减法会产生延迟。所有三个应用程序(发件人，应用程序， tcpdump都在同一台计算机上)。

首先针对虚拟接口的服务器硬件

i7桌面硬件针对虚拟接口

注意Y轴比例差异。服务器为0-4秒，i7桌面为0-1秒。似乎难以阅读的X轴是数据包编号。

下次尝试

我正在运行该应用程序的本地集成版本。然后，我消除了应用程序开始完成的几乎100％的工作，并发现服务器硬件上的延迟越来越大。然后，我尝试使用 -Xmx100G -Xms100G从本质上阻止垃圾收集器运行EVER，并看到以下结果(小于1秒的一致延迟)。

这导致了我 Java 8's Available Garbage Collectors。

服务器硬件上的默认垃圾收集器选择为“新:ParallelScavenge”，旧:“ParallelOld”。这是没有XML转换的结果延迟图，这是我可以使其重现问题的简单测试。

显式选择Garbage First Garbage Collector -XX:+UseG1GC选择New:G1New，Old:G1Old，它的延迟图也不是很好:

显式选择并发标记扫描垃圾收集器 -XX:+UseConcMarkSweepGC选择新的:ParNew，旧的:ConcurrentMarkSweep，它产生的延迟图看起来非常好:

看来问题已解决。将所有组件添加回原位后，我仍然会遇到无法接受的延迟。我仍在运行测试以查看是否可以隔离问题。

跟踪结果

尝试 strace -c -o /path/to/file -f产生以下顶级系统调用

首先是i7的桌面 strace报告(在前10个项目中被截断)

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 93.71 1418.604132         959   1479659    134352 futex
  1.74   26.294223      730395        36           poll
  1.74   26.288786         314     83645         4 read
  1.41   21.373672          73    293618           epoll_pwait
  1.19   17.952475         120    149854         2 recvfrom
  0.10    1.448453           2    909731           getrusage
  0.06    0.896903           3    281407           sendto
  0.03    0.394695           2    198041           write
  0.01    0.182809          10     18246           mmap
  0.01    0.120735           6     20582           sched_yield

现在针对服务器的 strace报告:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 97.46 2119.311196        2642    802183    131276 futex
  1.28   27.734136     6933534         4           poll
  0.59   12.840448          49    263597           epoll_wait
  0.41    8.885742         113     78387         2 recvfrom
  0.07    1.575401           6    263671           sendto
  0.07    1.515999           6    262256           epoll_ctl
  0.04    0.902788          54     16800           sched_yield
  0.03    0.743231          10     75455           write
  0.02    0.490052           6     84509         7 read
  0.01    0.170152           4     42732           lseek

我不清楚我应该从中得出什么结论。在 futex和 poll系统调用中，桌面速度要快许多倍。我仍然不明白为什么该应用程序对更快的硬件有更多的潜能。

剖析

我在这两种硬件上都介绍了该软件，并显示了热点的相似位置，这似乎可以排除这一点。

Answer 1

我确认我在RedHat中使用了performance CPU调节器:CPUfreq Coverners

我遇到了有关BIOS设置Virtual Machine Application runs slower than expected on EXSi问题的VMWare ESXi报告

这直接指向了我的答案。该Dell R630的默认设置为“每瓦性能(DAPC)”(DAPC:Dell Active Power Controller)。切换到“性能”可以完全解决此问题。机器在控制台上感觉更加敏捷，并且延迟远低于台式机所能达到的延迟，这是我预期的CPU差异。

在启动时更改Dell R630(可能还有其他)上的BIOS的步骤:

F2进入系统设置程序

选择“系统BIOS”

选择“系统配置文件设置”

确保第一个条目设置为“Performance”，默认值为“Performance Per Watt”

选择“返回”

选择“完成”

选择“是”以通过系统重置保存更改

选择“确定”将设置保存成功

这是产生的延迟图，它们使用相同的1秒刻度。

服务器上的默认GC:

服务器上的并发标记扫描GC:

服务器上的第一代GC:

G1GC和CMSGC之间的差别不大，但两者的延迟明显比默认值(预期的)要好。

逻辑核心时钟速度图

符号很难看到，但是这两张图上有32个不同的点。总体而言，您可以快速分辨出哪个是性能，哪个是每瓦dapc性能。

每瓦性能(DAPC):

性能

一起绘制。红色子弹性能，蓝色空心圆圈中的每瓦性能

这是在300秒的数据流期间捕获的，并相应设置了BIOS。如果有人想知道，这是我捕获数据的方式:

for i in `seq 300`; do
  paste /sys/devices/system/cpu/cpu[0-9]*/cpufreq/cpuinfo_cur_freq
  sleep 1
done > performance.log