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:
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.)