2017-08-21 2 views
9

J'ai lu et lu des articles sur pourquoi System.nanoTime() est plus lent sur certains systèmes d'exploitation que d'autres, mais je n'ai jamais rien vu pour expliquer la différence que je vois maintenant. En utilisant JMH, j'exécute ce benchmark. (Note: il utilise System.nanoTime() ainsi)Centos 7, 400x plus lent pour System.nanoTime que Windows

@Benchmark 
public long systemNanoTime() { 
    return System.nanoTime(); 
} 

Sous Windows 10, cela prend ~ 25 ns.

Sur Centos 7, Linux 3.10 est mesurée comme prenant ~ 10293 ns.

C'est sur la même machine, Intel (R) Core (TM) CPU @ 3.60GHz i7-7820X

Y at-il une possibilité de changer la façon dont le JDK obtient l'horloge du système?


EDIT: Basé sur le lien fourni par Todd, il semble que tsc n'est pas disponible

# more /sys/devices/system/clocksource/clocksource0/* 
:::::::::::::: 
/sys/devices/system/clocksource/clocksource0/available_clocksource 
:::::::::::::: 
hpet acpi_pm 
:::::::::::::: 
/sys/devices/system/clocksource/clocksource0/current_clocksource 
:::::::::::::: 
hpet 

après avoir effectué

echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource 

La latence améliorée, mais reste faible avec un latence de 1 816 ns.

J'ai essayé de savoir si la source d'horloge TSC peut être ajoutée à Centos, mais pas encore de chance.


EDIT: Creuser un peu plus loin que je suivais cette page basée sur la suggestion de @ apangin

# 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 
+0

Avez-vous regardé ce billet? Il décrit certains de ce que vous voyez et semble bien documenté. http://pzemtsov.github.io/2017/07/23/the-slow-currenttimemillis.html – Todd

+2

Cela ressemble à un bug de firmware. Je pense avoir vu des correctifs de synchronisation tsc dans les nouveaux noyaux (comme 4.10). – apangin

Répondre

6

sur l'ajout du référentiel alternatif pour CentOS avec la dernière version

http://elrepo.org/tiki/tiki-index.php

et puis suivi les instructions supplémentaires ici

https://www.tecmint.com/install-upgrade-kernel-version-in-centos-7/

après l'installation et le redémarrage

# $ 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 

suggérant le noyau est le réglage pour un bug du firmware.

Exécution du test à nouveau, j'obtiens une latence moyenne de 40 ns en utilisant System.nanoTime() qui est une amélioration de 260 fois. Cela signifie également que les points de référence utilisant cette mesure sont plus significatifs.