Oracle image for TestContainers in Java on Apple cpu

[ltpitt]

Hello,

I am experiencing significant performance issues when running integration tests using the Testcontainers Oracle PDB image on my Apple M1 Pro (32GB RAM).
Due to the ARM architecture of my Mac, I am using Colima to manage Docker containers. Here are the details of my setup and the steps I have taken:

System Configuration:

Device: Apple M1 Pro
RAM: 32GB
Docker Management Tool: Colima
Steps Taken:

Started Colima with the following configuration:
colima start --arch x86_64 --vm-type vz --cpu 8 --memory 16
Enabled container reuse in testcontainers.properties:
testcontainers.reuse.enable=true
Configured the Oracle container with .withReuse(true) in the code.
Despite these optimizations, the integration tests remain very slow and almost unusable. The qemu-system process consumes a significant amount of CPU and memory, indicating that the emulation might be causing the slowdown.

Request:

Could you suggest any additional techniques or configurations to improve the performance of the Testcontainers Oracle PDB image on an Apple M1 Pro?
Is there an ARM64-compatible version of the Oracle PDB image available that I can use to avoid the overhead of emulation?

Thank you for your assistance and patience.

[gvenzl]

Hi @ltpitt,

Thanks for using these images!

Is there an ARM64-compatible version of the Oracle PDB image available that I can use to avoid the overhead of emulation?

Yup, there is. Throw Colima away and just pull the latest version. Docker will automatically pull the ARM one. :)

[ltpitt]

I cry hot tears of joy!

Thank you!

But I still get the same error, what am I doing wrong?:
docker-compose up --build --force-recreate
[+] Running 1/0
⠋ Container oracle_local Creating 0.0s
! oracle-xe The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested 0.0s
Error response from daemon: {"message":"No such container: d041ea01785bed46e42a703acf9e9315739b0fddff0cb1f62b66e5bebc2ac972"}

My Dockerfile:
services:
oracle-xe:
image: gvenzl/oracle-xe:21-slim-faststart
container_name: oracle_local
ports:
- "1521:1521"

[ltpitt]

Ah, wait!
Starting with Oracle Database 23.5 Free, Oracle provides ARM ports for Oracle Database Free. Multi-platform (multi-arch) images for Oracle Database Free are provided at docker.io/gvenzl/oracle-free and ghcr.io/gvenzl/oracle-free .

[gvenzl]

Exactly, don't use gvenzl/oracle-xe, use gvenzl/oracle-free :)

Hopefully, the tears didn't drown your Mac :)

[ltpitt]

It works awesome, deeply thank you!

Give the fact I am speaking with the creator himself...
Allow me to fish for a suggestion, if I may.

I use your image in testcontainers to test a java app but, as you might imagine, startup is quite slow.
Do you have any "special sauce" to tackle this scenario?

Deeply thanks and, again, congratulations for the great work.

[gvenzl]

I'm glad to hear it and thank you for your kind words!

There are a couple of tricks that might work, but ultimately, it comes down to how fast the pull of the image and how fast the extraction vs. startup time are.

You might find that using the non-faststart image (the one without having -faststart) might actually be quicker to spin up than the faststart one, because it downloads faster and the extraction time may outperform the download of the additional bits. You can read up on an experiment I did over here: gvenzl/oci-oracle-xe#36 (comment)

The most important thing is to avoid pulling the image over and over again. I'm not a Testcontainers expert and don't know whether it does or doesn't do that but a discussion over here indicates that it throws the image away right away again.
So perhaps using the mentioned environment variable can help too.
Of course, this is only helpful if you start multiple containers during your tests, causing multiple image downloads. If you only have one, you will probably have no other choice but to pay the download penalty once.

Outside of image download, given that you are using the -faststart image already, the actual database startup is usually done within a couple of seconds.

I hope this helps!

[ltpitt]

Thanks for your kind help and pointers, I will read avidly :)

Have an awesome day!

[gvenzl]

Thank you, you too!