
In a previous post we explained the benefits of moving a long time running java workload to OCI. Today we are showing the benefits we get by changing the jdk.
Procedure
The procedure was quite simple: We installed jdk13 in the hosts and started the nodes to see what happens. The first intent failed because the flag -XX:+AggressiveOpts is not supported in jdk13, so we removed it and started again. Hopefully no other changes were needed nor done and the process ended successfully. Let’s see the numbers:
JDK | TIME |
jdk8 | 8h34min |
Open jdk13 | 6h38min |
Oracle jdk13 | 6h24min |
Conclusion 1
With jdk13 we got an improvement of 20%+just changing the SDK.
Testing brand new GC’s Algorithms
In a second step we tested the new garbage collectors. This features are not available yet in Oracle’s jdk, therefore we only tried with openjdk.
First, we set the ZGC [-XX:+UnlockExperimentalVMOptions -XX:+UseZGC] and started the process but it didn’t finished well throwing errors related to coherence:
20:37:42.654 ERROR e.m.s.p.AppGridPlanificador - Error recuperando progreso de tarea de vlam001 motor-2 com.tangosol.io.pof.PortableException: Tried to execute method:getProgress but Entry is null, key:Identifier{0x0000016F0B0C76C80AFBEA0A3B3E93A2CC0BD3F3C0A246DCCF6F871F776F320D} at com.tangosol.io.pof.ThrowablePofSerializer.deserialize(ThrowablePofSerializer.java:57) ~[coherence.jar:12.1.2.0.0] at com.tangosol.io.pof.PofBufferReader.readAsObject(PofBufferReader.java:3316) ~[coherence.jar:12.1.2.0.0] at com.tangosol.io.pof.PofBufferReader.readObject(PofBufferReader.java:2604) ~[coherence.jar:12.1.2.0.0] at com.tangosol.io.pof.ConfigurablePofContext.deserialize(ConfigurablePofContext.java:376) ~[coherence.jar:12.1.2.0.0] at com.tangosol.util.ExternalizableHelper.deserializeInternal(ExternalizableHelper.java:2791) ~[coherence.jar:12.1.2.0.0] at com.tangosol.util.ExternalizableHelper.fromBinary(ExternalizableHelper.java:266) ~[coherence.jar:12.1.2.0.0] at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.partitionedService.PartitionedCache$ConverterFromBinary.convert(PartitionedCache.CDB:4) ~[coherence.jar:12.1.2.0.0] at com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.partitionedService.PartitionedCache$ViewMap.invoke(PartitionedCache.CDB:24) ~[coherence.jar:12.1.2.0.0] at com.tangosol.coherence.component.util.SafeNamedCache.invoke(SafeNamedCache.CDB:1) ~[coherence.jar:12.1.2.0.0] at com.oracle.coherence.common.util.NamedCacheObjectProxy.invoke(NamedCacheObjectProxy.java:111) ~[coherence-common-12.1.0.jar:na] at com.sun.proxy.$Proxy11.getProgress(Unknown Source) ~[na:na]
In a second try we set Shenandoah with -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC but unfortunately the java processes crashed in the startup, don’t wanna lose more time for now so I give up happy with the improvement with zero effort…
Conclusion 2
For a long time running workload like the mentioned, garbage collectors didn’t provide any advantage compared with the one obtained by just swaping the jdk version.
Disclaimer
The results obtained here can’t be in any case extrapolated, things are not that simple and only idiots believe that one size fits all…
That’s all folks, hope it helps! 🙂