Centos 7,System.nanoTime 比 windows 慢 400 倍
Centos 7, 400x slower for System.nanoTime than windows
我已经看到并阅读了关于为什么 System.nanoTime() 在某些操作系统上比其他操作系统慢的帖子,但是我从来没有看到任何东西来解释我现在看到的差异。使用 JMH,我是 运行 这个基准。 (注意:它也使用 System.nanoTime())
@Benchmark
public long systemNanoTime() {
return System.nanoTime();
}
在 Windows 10 上,这需要大约 25 ns。
在 Centos 7 上,Linux 3.10 测得耗时约 10293 ns。
这是在同一台机器上,Intel(R) Core(TM) i7-7820X CPU @ 3.60GHz
是否可以选择更改 JDK 获取系统时钟的方式?
编辑:根据 Todd 提供的 link,tsc 似乎不可用
# more /sys/devices/system/clocksource/clocksource0/*
::::::::::::::
/sys/devices/system/clocksource/clocksource0/available_clocksource
::::::::::::::
hpet acpi_pm
::::::::::::::
/sys/devices/system/clocksource/clocksource0/current_clocksource
::::::::::::::
hpet
执行后
echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource
延迟有所改善,但仍然很差,延迟为 1,816 ns。
我试过Centos是否可以添加TSC时钟源,但还没有运气。
编辑:进一步挖掘
# dmesg | grep -i tsc
[ 0.000000] tsc: Detected 3600.000 MHz processor
[ 0.058602] TSC deadline timer enabled
[ 0.065868] TSC synchronization [CPU#0 -> CPU#1]:
[ 0.065870] Measured 679995254538 cycles TSC warp between CPUs, turning off TSC clock.
[ 0.065874] tsc: Marking TSC unstable due to check_tsc_sync_source failed
[ 125.451480] Override clocksource tsc is not HRT compatible. Cannot switch while in HRT/NOHZ mode
根据@apangin 的建议,我按照此页面添加了最新版本的 centos 替代存储库
http://elrepo.org/tiki/tiki-index.php
然后按照此处的进一步说明进行操作
https://www.tecmint.com/install-upgrade-kernel-version-in-centos-7/
安装并重启后
# $ dmesg | grep -i tsc
[ 0.001000] tsc: Detected 3600.000 MHz processor
[ 0.001000] [Firmware Bug]: TSC ADJUST: CPU0: -2100392876408 force to 0
[ 0.046075] TSC deadline timer enabled
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU1: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU2: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU3: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU4: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU5: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU6: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU7: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU8: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU9: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU10: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU11: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU12: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU13: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU14: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU15: 0
[ 1.337843] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x6c1bafbc2ab, max_idle_ns: 881591058496 ns
[ 2.353636] clocksource: Switched to clocksource tsc
建议内核正在针对固件错误进行调整。
运行 再次测试,我使用 System.nanoTime() 获得了 40 ns 的平均延迟,这是 260 倍的改进。这也意味着使用此度量的基准更有意义。
我已经看到并阅读了关于为什么 System.nanoTime() 在某些操作系统上比其他操作系统慢的帖子,但是我从来没有看到任何东西来解释我现在看到的差异。使用 JMH,我是 运行 这个基准。 (注意:它也使用 System.nanoTime())
@Benchmark
public long systemNanoTime() {
return System.nanoTime();
}
在 Windows 10 上,这需要大约 25 ns。
在 Centos 7 上,Linux 3.10 测得耗时约 10293 ns。
这是在同一台机器上,Intel(R) Core(TM) i7-7820X CPU @ 3.60GHz
是否可以选择更改 JDK 获取系统时钟的方式?
编辑:根据 Todd 提供的 link,tsc 似乎不可用
# more /sys/devices/system/clocksource/clocksource0/*
::::::::::::::
/sys/devices/system/clocksource/clocksource0/available_clocksource
::::::::::::::
hpet acpi_pm
::::::::::::::
/sys/devices/system/clocksource/clocksource0/current_clocksource
::::::::::::::
hpet
执行后
echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource
延迟有所改善,但仍然很差,延迟为 1,816 ns。
我试过Centos是否可以添加TSC时钟源,但还没有运气。
编辑:进一步挖掘
# dmesg | grep -i tsc
[ 0.000000] tsc: Detected 3600.000 MHz processor
[ 0.058602] TSC deadline timer enabled
[ 0.065868] TSC synchronization [CPU#0 -> CPU#1]:
[ 0.065870] Measured 679995254538 cycles TSC warp between CPUs, turning off TSC clock.
[ 0.065874] tsc: Marking TSC unstable due to check_tsc_sync_source failed
[ 125.451480] Override clocksource tsc is not HRT compatible. Cannot switch while in HRT/NOHZ mode
根据@apangin 的建议,我按照此页面添加了最新版本的 centos 替代存储库
http://elrepo.org/tiki/tiki-index.php
然后按照此处的进一步说明进行操作
https://www.tecmint.com/install-upgrade-kernel-version-in-centos-7/
安装并重启后
# $ dmesg | grep -i tsc
[ 0.001000] tsc: Detected 3600.000 MHz processor
[ 0.001000] [Firmware Bug]: TSC ADJUST: CPU0: -2100392876408 force to 0
[ 0.046075] TSC deadline timer enabled
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU1: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU2: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU3: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU4: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU5: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU6: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU7: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU8: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU9: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU10: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU11: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU12: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU13: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU14: 0
[ 0.001000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -2100392876408 CPU15: 0
[ 1.337843] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x6c1bafbc2ab, max_idle_ns: 881591058496 ns
[ 2.353636] clocksource: Switched to clocksource tsc
建议内核正在针对固件错误进行调整。
运行 再次测试,我使用 System.nanoTime() 获得了 40 ns 的平均延迟,这是 260 倍的改进。这也意味着使用此度量的基准更有意义。