[
https://issues.apache.org/jira/browse/BEAM-13073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17448214#comment-17448214
]
Valentyn Tymofieiev commented on BEAM-13073:
--------------------------------------------
Looks like the command for the benchmark in question looks like so:
{noformat}
04:48:50 Build step 'Invoke Gradle script' changed build result to SUCCESS
04:48:50 [beam_LoadTests_Java_ParDo_Dataflow_V2_Batch_Java11] $ /bin/bash -xe
/tmp/jenkins8325135391935297727.sh
04:48:50 + echo '*** Load test: ParDo 2GB 100 byte records 200 times ***'
04:48:50 *** Load test: ParDo 2GB 100 byte records 200 times ***
04:48:50 [Gradle] - Launching build.
04:48:50 [src] $
/home/jenkins/jenkins-slave/workspace/beam_LoadTests_Java_ParDo_Dataflow_V2_Batch_Java11/src/gradlew
-PloadTest.mainClass=org.apache.beam.sdk.loadtests.ParDoLoadTest
-Prunner=:runners:google-cloud-dataflow-java
'-PloadTest.args=--project=apache-beam-testing --region=us-central1
--appName=load_tests_Java11_Dataflow_V2_batch_ParDo_2
--tempLocation=gs://temp-storage-for-perf-tests/loadtests
--influxMeasurement=java_batch_pardo_2
--influxTags={"runnerVersion":"v2","jdk":"java11"} --publishToInfluxDB=true
--sourceOptions={"numRecords":20000000,"keySizeBytes":10,"valueSizeBytes":90}
--iterations=200 --numberOfCounters=1 --numberOfCounterOperations=0
--numWorkers=5 --autoscalingAlgorithm=NONE --streaming=false
--influxDatabase=beam_test_metrics --influxHost=http://10.128.0.96:8086
--runner=DataflowRunner' -Prunner.version=V2 -PcompileAndRunTestsWithJava11
-Pjava11Home=/usr/lib/jvm/java-11-openjdk-amd64 --continue --max-****s=12
-Dorg.gradle.jvmargs=-Xms2g -Dorg.gradle.jvmargs=-Xmx4g
-Dorg.gradle.vfs.watch=false -Pdocker-pull-licenses
:sdks:java:testing:load-tests:run
{noformat}
Looking further in the logs, it seems that container is being rebuilt, which is
good.
Technically, we should be able to trigger this suite on a PR with trigger
commands, but the feedback loop would be longer and we might write the updated
result into metrics database.
I'll try a targeted execution.
> Unexpected GC when using Java 11
> --------------------------------
>
> Key: BEAM-13073
> URL: https://issues.apache.org/jira/browse/BEAM-13073
> Project: Beam
> Issue Type: Bug
> Components: sdk-java-harness
> Reporter: Luis
> Assignee: Kenneth Knowles
> Priority: P1
> Labels: java11, java9, performance
> Fix For: 2.35.0
>
> Attachments: perf_regression_java_11.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Beam SDK has been supporting Java 11 for a while (I guess the support was
> introduced here https://issues.apache.org/jira/browse/BEAM-2530).
> Unfortunately, in Spotify we are still experiencing performance issues when
> using Beam SDK 2.32, Google Dataflow and Java 11.
> Thanks to [~emilyye] and [~iht], they confirmed JVM 11 is using SerialGC,
> while Java 8 uses ParallelGC. It sounds like ParallelGC is a good option for
> high throughput / low latency jobs. For Java11 we'd expect to use G1GC or
> ParallelGC.
> This SO question [1] clarifies that JVM chooses SerialGC when it treats the
> machine as a "client". It looks like the Java SDK container could benefit
> from using `-XX:+AlwaysActAsServerClassMachine`. Is that correct?
> Let me know if the ticket needs further context or adjustment. (It is my
> first time creating a ticket here).
> [1]
> [https://stackoverflow.com/questions/52474162/why-is-serialgc-chosen-over-g1gc]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
