For testing purposes many IT-people traditionally use Virtual Machines (VMs) on their Laptops (often on Oracle Virtualbox). Since Apple moved to its own processor type (Apple Silicon, i.e. ARM architecture), it’s no longer possible to run VMs based on Intel x86-64 on Apple ARM (e.g. on Apple MacBook Pros with M1 or M2 processors). I.e. as the Oracle Database does not run on ARM, a workaround is necessary for e.g. a Consultant with an Apple Laptop to be able to run tests against Oracle databases on that Laptop.
What are the alternatives?
- runinng the DB-server VM on the Cloud (requires access to the cloud resources over the internet)
- running the DB-server on separate hardware (requires access to separate hardware. So you need to carry the hardware with you or provide remote access to it, e.g. over VPN)
Another potential alternative would be the emulation of x86-64 on ARM. I.e. on Mac that means running QEMU. The product UTM makes that easy as it adds a GUI on top of QEMU.
According lots of feedback on the internet the emulation is VERY SLOW. I thought I’ll check that myself on what “very slow” means in terms of running an Oracle database in an emulated environment.
Here’s the environment I’m in:
- MacBook Air (M1, 2020), 8GB RAM
- UTM version 3.2.4. from Turing Software LLC (can be downloaded from the App Store) and costs $10
For testing purposes I created 2 VMs:
- Ubuntu Linux with Oracle XE on Docker
- Oracle Linux 8.x with Oracle EE 19.16.
First of all the good news is that I could install and run the 2 environments without any crash. Everything runs very stable as long as the UTM System setting “Force Multicore” is not enabled. In that case UTM can only use 1 core of the Mac. That’s very stable. With “Force Multicore” enabled more than 1 Core can be used from the Mac on the VM. In my case that was fast, but running Java in the VM did not work anymore. I had to disable cores then to make Java work (see the summary below on how I did that).
Now to the main question: What is the performance of the DB-server running in the emulated UTM-VM?
It takes considerable more time to install the environment and it of course feels much slower than running a type 2 hypervisor (like Virtualbox on native x86_64). But I wanted to know exact numbers, so I did a couple of tests:
1.) Running datapatch against a CDB with 1 PDB (part of dbca after installing 19.16. software only):
This test was performed with “Force Multicore” disabled.
1 Core for the VM on the emulated environment:
- Patch CDB: 2h, 37min, 23sec
- Patch PDB$SEED and PDB1: 1h, 41min, 30sec
I did run the same on a virtualbox on a MacBook Pro with a 2.6 GHZ Core i7:
2 Cores for VM on type 2 hypervisor on native x86_64:
- Patch CDB: 8min, 15sec
- Patch PDB$SEED and PDB1: 5min, 32sec
Result: Emulated VM with half the cores is approx factor 18 slower than on the native machine.
REMARK: All tests performed for this Blog were done on those 2 machines (MacBook Air 2020 M1 with emulated UTM-VM versus MacBook Pro 2019 Intel with Virtualbox).
2.) A pure DB-CPU-Load test
To utilize a DB sever on CPU I usually run the following cpu_load.sql-script in sqlplus:
set lines 120 set timing on time on with t as ( select rownum from dual connect by level <= 60) select /*+ ALL_ROWS */ count(*) from t,t,t,t,t /
I.e. the dedicated server process runs 100% on CPU for a couple of secs. This is a single thread performance test and is not related to the number of active cores as the test runs on 1 core only. The results were:
UTM (emulated): 3min, 33sec
Virtualbox (native): 15.5 secs
–> The emulated VM is 13.75 times slower
3.) CPUSPEED in the Oracle system statistics
The CPUSPEED of system stats in aux_stats$ shows 342 for that emulated machine (342 millions of instructions per second). I gathered system statistics while running a swingbench test:
The performance cores of the M1 run between 600 – 3204 MHz. I.e. the emulated environment is approximately 3204/342 = 9.4 times slower from an Oracle perspective.
Loaded Swingbench data with the oewizard by leaving everything on default except the load factor and the parallelism. I took a load factor 0.7 and a parallelism of 2. The total runtime for the load was 17min, 52secs and it inserted 14’569 rows /sec:
Doing the same against Virtualbox on a native Intel environment looked as follows:
I.e. 14569 rows inserted per second on the emulated environment compared to 75966 rows per second on Virtualbox (factor 5.2). But as I just ran with a parallelism of 2, I probably haven’t used the available resources effectively.
Running charbench for 1 min on the emulated environment with 8 Users (the number of 8 sessions brought the best TPS-rate) showed approx 55 TPS (on the 2 cores configured VM with “Force Multicore”):
On the native Intel environment configured with 2 cores as well I could achieve 770 TPS with 55 sessions:
So that’s a factor of 14 higher TPS on a 2 cores VM.
Summary: It’s possible to run an Oracle DB in a VM on an Apple Silicon machine, but you have to use hardware emulation, which makes the processing on the DB slower by a factor of 10 – 14 compared to a Type 2 hypervisor (e.g. Virtualbox). This is OK for doing functional tests, but is usually too slow for heavy testcases or regular installations or upgrades. For best performance enable “Force Multicore”, but then Java did not work anymore in my tests (e.g. a command “$ORACLE_HOME/OPatch/opatch lspatches” did not finish). To workaround the Java issue I disabled all cores except 1, ran the Java program and enabled all cores again. E.g. on a VM with 2 cores enabled (cpu0 and cpu1):
Disable cpu1 as root temporarily:
# echo 0 > /sys/devices/system/cpu/cpu1/online
Run your Java program:
[[email protected] ~] $ORACLE_HOME/OPatch/opatch lspatches
Enable cpu1 as root again:
# echo 1 > /sys/devices/system/cpu/cpu1/online
The DB itself was not affected negatively during my tests with “Force Multicore” enabled. I do recommend to use “Force Multicore” enabled as it makes a huge difference: