Support building and testing Alluxio on ARM64 platform #12704
Comments
liusheng
changed the title
|
@liusheng Thanks for making this request. Have you already identified platform dependent issues when using ARM64? |
|
@calvinjia |
|
Thanks for the details, these would be necessary for developing Alluxio on ARM64, which I think is a more far off goal. Do yo know if the Alluxio system (pre-compiled) runs fine on ARM64? |
|
@calvinjia We are running our Alluxio+Presto clusters on Graviton2 instances in production for several weeks. There were some setbacks in several places, but we managed to have it operational. We observed a significant performance degradation in both Alluxio and Presto clusters when using the official Docker images. We found out, that Amazon Corretto JVM eliminates this performance degradation. |
|
@jpohanka Thanks for reporting this! |
|
Hi @calvinjia,
Because the above two issues, the first one only do Protobuf Backwards Compatibility Check and second one only effect the webui module. So maybe the pre-compiled package of Alluxio can be directly run on ARM64 server. I will try to verify this. HI @jpohanka, |
|
Since the protolock maven plugin is merely a linter, you can disable it using a platform specific maven build profile. |
|
Protolock maven plugin now includes arm64 support https://github.com/salesforce/proto-backwards-compat-maven-plugin/releases/tag/v1.0.6 |
|
Hi @rmichela , |
|
I am trying to build Alluxio on Linux ARM64 but AlluxioFuseFileSystemTest fails with: It passes fine on x86_64. Any hints what might be the reason and how to debug it ? |
|
I think I've found the problem with jnr-ffi - jnr/jnr-ffi#283 (comment) |
|
jnr/jnr-ffi#284 fixes the problem with jnr-ffi and AlluxioFuseFileSystemTest passes fine now! The next problem is with I will try to debug it! |
|
The problem seems to be in Netty native. I've updated Netty to 4.1.70 and netty-tcnative-boringssl to 2.0.46 but still it breaks. |
This fixes AlluxioFuseFileSystemTest on Linux ARM64 Also see jnr/jnr-ffi#284 While here also update jnr-fuse to 0.5.7
|
@ Alluxio team: We have found the problem with Netty - netty/netty-tcnative#681 (comment). The reason is that the Ratis dependency brings libnetty-tcnative-**.so as well. |
|
@martin-g thanks for this finding. should we hold off on any netty upgrades until this issue is resolved? |
|
@yuzhu Do you know whether Alluxio Tests failures are related to jnr-fuse: I will investigate more tomorrow! |
|
So yes, you should not upgrade Netty to 4.1.71 or newer before Ratis team fixing https://issues.apache.org/jira/browse/RATIS-1443 |
…erver ratis-thirdparty-misc brings old versions of netty-tcnative-boringssl-static that breaks the **ProcessMonitorTest's
|
The problem with JNRFuseIntegrationTest is: |
|
I will need help with the problem of I'm attaching the logs of diff --git tests/src/test/resources/log4j.properties tests/src/test/resources/log4j.properties
index 06e6a8ad22..8456301807 100644
--- tests/src/test/resources/log4j.properties
+++ tests/src/test/resources/log4j.properties
@@ -51,3 +51,8 @@ log4j.appender.PROXY_LOGGER.MaxFileSize=10MB
log4j.appender.PROXY_LOGGER.MaxBackupIndex=100
log4j.appender.PROXY_LOGGER.layout=org.apache.log4j.PatternLayout
log4j.appender.PROXY_LOGGER.layout.ConversionPattern=%d{ISO8601} [%t] %-5p %c{1} - %m%n
+
+log4j.logger.alluxio.fuse.AlluxioFuseFileSystem=debug
+log4j.logger.alluxio.client.file.FileSystemContext=debug
+log4j.logger.io.netty.handler.ssl=debug
+log4j.logger.io.netty.util.internal.NativeLibraryLoader=debugOn AMD64 I see: But on ARM64 the |
|
It appeared that jnr-fuse does not support Linux ARM64 at all: SerCeMan/jnr-fuse#14 |
|
hi there, I'm working at building alluxio on arm64(KunpengCPU) but failed with: and stack is: env info: I've add maven profile of os like this below: but it does not work. Any suggestion will be grateful. |
|
Hi @JunLuo ! |
|
Hi @martin-g |
|
You can work it around by adding Another property that could help is |
|
It work and I success built in kunpeng CPU, Thanks a lot! |
|
@cheyang , with the continuation of our discussion here, I tried building Alluxio docker images using the build-image.sh script for Linux/ARM64. I edited go installation for ARM64 in tarball.sh. Also, the maven version 3.6.2-jdk-8 used in the build-image.sh script does not support Linux/ARM64. I updated maven to 3.8.6-openjdk-8. And then executed below command:
Build is failing for Linux/ARM64 with the logs below: However, after updating maven to 3.8.6-openjdk-8 for Linux/AMD64, build-image.sh also fails with the logs below: It seems that some of the alluxio’s dependencies also need updations to match updated maven version and to support Linux/ARM64. |
|
I can confirm targeting ARM platform works, and I successfully built and pushed the image here: https://hub.docker.com/r/naushadh/alluxio/tags $ git clone https://github.com/Alluxio/alluxio.git
$ cd integrations/docker
$ docker build -t alluxio/alluxio:2.8.1 --platform arm64 .
$ docker tag alluxio/alluxio:2.8.1 naushadh/alluxio:2.8.1
$ docker push naushadh/alluxio:2.8.1Would be nice if this can be done by the CI process so there is official Docker images that work in ARM. |
|
Thanks you very much @naushadh Thanks |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in two weeks if no further activity occurs. Thank you for your contributions. |
github-actions
bot
added
the
stale
|
@duduhandelman nothing special, you should be able to follow the steps I'd shared above. |
github-actions
bot
removed
the
stale
@naushadh I tried naushadh/alluxio:2.8.1 on my aarch64 machine and get this: Seems this image can not run on aarch64 |
Is your feature request related to a problem? Please describe.
Currently, more and more softwares have supported running on ARM64 platform, it would be good if Alluxio also support running and testing on ARM platform.
Describe the solution you'd like
Try to make Alluxio can be sucessfully built and run all the test cases passed on ARM64 server, and then setup ARM CI job for Alluxio project to make sure future development won't break ARM64 support.
Describe alternatives you've considered
N/A
Urgency
Medium
Additional context
N/A
The text was updated successfully, but these errors were encountered: