multithreadingvirtualboxcpuvirtualizationstarvation

Is there a maximum number of CPU's that a VirtualBox could bare?


I am using VirtualBox 5.1 running in a host with 48 CPU's and 250GB of RAM the virtual machine that I am importing (the guest) initially had 2 CPU's and 4GB of RAM.

Inside this machine I am running a process with Java that starts a dynamic number of threads to perform some tasks.

I ran it with configurations below:

The whole process in my laptop (2 CPUs/4GB RAM) ~ 11 seconds

same program in the virtual machine in the server (15 CPUs and 32GB of RAM) ~ 45 seconds

same program in the virtual machine in the server (20 CPUs and 32GB of RAM) ~ 100+ seconds

same program in the virtual machine in the server (10 CPUs and 32GB of RAM) ~ 5+ seconds

First I thought that there was a problem in how I was managing the threads from Java but after many tests I figured out that there was a relation between the number of CPU's that the virtual machine has and its performance, the maximum was 10, after that the overall performance of the machine slows down(CPU starvation?)

The virtual machine runs Oracle Enterprise Linux 6.7 and the host runs Oracle Enterprise Linux 6.9

I couldn't found any hard limit in the Virtual Machine documentation regarding the number of CPU's.

Is there a setting that needs to be set to enable/take advantage of more than 10 CPU's in a VirtualBox instance?


Solution

  • Time has happened since I posted this question, just for the archive I will share my findings hoping they can help to save time for others.

    It turns out that the performance issues were due to the way how VirtualBox works. Especially the relationship between the OS and the hypervisor.

    The Virtual Machine (the guest OS) at the end is a single process for the host and when you modify the number of CPU's in the Virtual Machine settings what they will do is change the number of threads that the process will have to emulate the other CPU's. (at least in VirtualBox)

    Having said that, when I assigned 10+ CPUs to the VM I ended up with:

    All of that together caused that the setup was saturating the host Virtual Machine process which I think it was due to the way how the host OS was handling the processes context switching

    On my server, the hard limit was 7 virtual CPU's, if I added more than that it would slow down the performance of the Java software

    Running the Java software outside of the VM didn't show any performance issue, it worked out of the box with 60+ isolated threads.