Shulou(Shulou.com)06/01 Report--

This article is to share with you the content of the sample analysis of quarkus supersonic startup after GraalVM native-image compilation. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Preface

Does quarkus's java stack, which claims to be supersonic subatomic JAVA tailored for Graalvm, live up to its name? Let's take a look at the real situation. Before we start, we briefly introduce Graalvm, which is an AOT compiler produced by oracle, which can compile applications into local images. Generally speaking, you can compile java into programs that can be executed directly by the machine. You can refer to the compilation output products of go language. And graalvm not only supports java, but also supports other languages. Let's first take a look at a diagram of the resource consumption of quarkus's java applications under traditional vm and graalvm.

Graalvm: https://www.graalvm.org/

Native-image compilation configuration native native io.quarkus quarkus-maven-plugin ${quarkus-plugin.version} native-image True true org.apache.maven.plugins maven-failsafe-plugin ${surefire-plugin.version} integration-test verify ${project.build.directory} / ${project.build.finalName}-runner org.jboss.logmanager.LogManager ${maven.home}

Using profile in the pom file adds a new native compilation environment, introduces the compilation plug-in of quarkus, and activates the compilation of native. In fact, this plug-in will only help you organize the graalvm compilation instructions, the graalvm environment also needs to be built by yourself, each iterative version of quarkus will be optimized for a specific graalvm version, so not all versions are compatible with each other. For example, the quarkus1.5.final version is compatible with the graalvm19.x version, and the latest quarkus1.6.final supports the graalvm20.1.1 version, and the download address of each version is the same as configuring the java environment. You can add the directory to the GRAALVM_HOME environment variable, such as:

Eventually, the maven compilation plug-in for quarkus will help us generate a graalvm compilation instruction like this:

F:\ runtime\ graalvm-ce-java8-19.3.1\ bin\ native-image.cmd-J-Dsun.nio.ch.maxUpdateArraySize=100-J-Djava.util.logging.manager=org.jboss.logmanager.LogManager-J-DCoordinatorEnvironmentBean.transactionStatusManagerEnable=false-J-Dvertx.logger-delegate-factory-class-name=io.quarkus.vertx.core.runtime.VertxLogDelegateFactory-J-Dvertx.disableDnsResolver=true-J-Dio.netty.leakDetection.level=DISABLED-J-Dio.netty.allocator.maxOrder=1-J-Duser.language=zh-J-Dfile.encoding=UTF-8 -- initialize-at-run-time=java.net.Inet4Address-H:+TraceClassInitialization-- initialize-at-build-time=-H:InitialCollectionPolicy=com.oracle.svm.core.genscavenge.CollectionPolicy$BySpaceAndTime-H:+JNI-jar kk-org-thansfer-admin-1.0-SNAPSHOT-runner.jar-H:FallbackThreshold=0-H:+ReportUnsupportedElementsAtRuntime-H:+ReportExceptionStackTraces-H:+AddAllCharsets-H:+IncludeAllTimeZones-H:EnableURLProtocols=http Https-enable-all-security-services-H:-UseServiceLoaderFeature-H:+StackTrace kk-org-thansfer-admin-1.0-SNAPSHOT-runner

The above is all the contents of the quarkus integrated graalvm compilation environment, but the compilation of graalvm under the windows system is not friendly. Bloggers have tried many methods, including mounting compilation through the docker container, and have failed, so if you have the same problem, see if our exceptions are the same:

[ERROR] Failed to execute goal io.quarkus:quarkus-maven-plugin:1.6.0.Final:native-image (default) on project kk-org-thansfer-admin: Failed to generate native image: io.quarkus.builder.BuildException: Build failure: Build failed due to errors [ERROR] [error]: Build step io.quarkus.deployment.pkg.steps.NativeImageBuildStep#build threw an exception: java.lang.RuntimeException: Failed to build native image [ERROR] at io.quarkus.deployment.pkg.steps.NativeImageBuildStep. Build (NativeImageBuildStep.java:366) [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0 (NativeMethod) [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62) [ERROR] at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) [ERROR] at java.lang.reflect.Method.invoke (Method.java:498) [ERROR] at io.quarkus.deployment.ExtensionLoader$2.execute (ExtensionLoader.java:932) [ERROR] at io.quarkus.builder .BuildContext.run (BuildContext.java:277) [ERROR] at org.jboss.threads.ContextClassLoaderSavingRunnable.run (ContextClassLoaderSavingRunnable.java:35) [ERROR] at org.jboss.threads.EnhancedQueueExecutor.safeRun (EnhancedQueueExecutor.java:2046) [ERROR] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask (EnhancedQueueExecutor.java:1578) [ERROR] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run (EnhancedQueueExecutor.java:1452) [ERROR] at java.lang.Thread.run (Thread.java:745) [ ERROR] at org.jboss.threads.JBossThread.run (JBossThread.java:479) [ERROR] Caused by: java.lang.RuntimeException: Image generation failed. Exit code:-1073741819 [ERROR] at io.quarkus.deployment.pkg.steps.NativeImageBuildStep.imageGenerationFailed (NativeImageBuildStep.java:416) [ERROR] at io.quarkus.deployment.pkg.steps.NativeImageBuildStep.build (NativeImageBuildStep.java:344) [ERROR]... 12 more [ERROR]-> [Help 1]

But don't panic, the blogger hasn't given up yet. Let's solve the problem by arranging multiple images of docker. Don't delete the pom configuration code posted above.

Docker multi-segment mirror choreography

# # Stage 1: build with maven builder image with native capabilitiesFROM quay.io/quarkus/centos-quarkus-maven:20.1.0-java8 AS buildCOPY pom.xml / usr/src/app/COPY src/ usr/src/app/srcUSER rootRUN chown-R quarkus/ usr/src/appUSER quarkusRUN mvn-f / usr/src/app/pom.xml-Pnative clean install-Dmaven.test.skip=true-Denv=DEV## Stage 2: create the docker final imageFROM registry.access.redhat.com/ubi8/ubi-minimalWORKDIR / work/COPY-- From=build / usr/src/app/target/*-runner / work/application# set up permissions for user `1001`Run chmod 775 / work/ work/application\ & & chown-R 1001 / work\ & & chmod-R "g+rwX" / work\ & & chown-R 1001:root / workEXPOSE 8080USER 1001CMD [". / application" "- Dquarkus.http.host=0.0.0.0"]

In the first stage, the centos basic image based on quarkus is built into the graalvm environment, and then we just need to copy the code and pom configuration into the system, and compile the environment in the same image into native-image. Then, in the second section, based on the basic image running environment of Little Red Riding Hood, the built product is copy, so the construction of the docker container is completed. However, in this way, all the dependencies are downloaded immediately, the requirements for the local network will be higher, and the overall compilation time will be longer. The compilation will fail with the slightest jitter in the network, so it is best to configure a faster domestic maven repository in pom, such as Aliyun's maven warehouse. Also, in the graalvm compilation phase, it will eat memory very much, at this time it will load all the code for static analysis, this piece of content Alibaba's jvm team has made optimization, may come to share later.

For problems that may be encountered, graalvm is initialized at compile time, and if you can only initialize at run time, you can add the following configuration to quarkus:

Quarkus.native.additional-build-args=--initialize-at-run-time=java.net.Inet4Address effect display

Although the compilation of docker will be relatively slow, it is successful in the end. The following shows the magic of quarkus. When the image runs successfully, the blogger can't resist the joy in his heart. He seems to have won 500W. Note that this program of the blogger is not a simple hello, but a production-level CURD program with data sources and interfaces.

Native-image startup time

Startup time under jvm

In addition to the n-fold increase in startup time, the memory footprint is also very touching. The total memory footprint of native-image in the container is only 90m, while that of applications under jvm is about 300m. Even so, it has performed very well compared to spring boot's frequent 1G memory footprint.

Thank you for reading! On the "GraalVM native-image compiled quarkus supersonic boot example analysis" this article is shared here, I hope the above content can be of some help to you, so that you can learn more knowledge, if you think the article is good, you can share it out for more people to see it!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.