If you're running a JVB on bare metal, check your clocksource!

We had a lab JVB today with suspiciously high CPU usage during load testing. I wrote up some of the details in a GitHub issue, but the short version is that it turns out that System.currentTimeMillis() is very slow (20x slower than normal) when the system it runs on uses the HPET clocksource, and JVB calls System.currentTimeMillis() a lot.

Linux usually defaults to TSC as clocksource rather than HPET, but if it decides (sometimes incorrectly) that the TSC is unstable, it will fall back to the HPET.

If you’re running JVB on bare metal, it would be worth checking the output of:

cat /sys/devices/system/clocksource/clocksource0/current_clocksource

If it’s hpet, try booting with hpet=disable and see if you get better performance. On our lab system, this gave us about 20x lower CPU usage for the same packet rate.

(If your JVB is on a VM, this probably isn’t relevant to you because the VM provider should provide a stable TSC clocksource, but you could still check.)