Achieving true parallelism with 500m CPU allocation in OpenShift 4 for a multi-threaded application

Question

Hello Stack Overflow community,

I have been working with OpenShift 4 to deploy a multi-threaded application that relies on parallelism for better performance. In OpenShift, fractional CPU amounts can be allocated using millicores. In my case, I have a scenario where I can only allocate 500m (500 millicores) CPU for my microservice.

The microservice has a main thread and a method that uses the @Async annotation to run asynchronously. Is there any way to guarantee true parallelism for these two threads, rather than just concurrency, when allocating 500m CPU?

Any guidance or suggestions on this topic would be much appreciated. Thank you!

I checked Dynatrace to understand the number of worker processes my application is using. I expected to see multiple worker processes running concurrently, but I only found one worker process in the graph when selecting "count".

Answer 1

In short, there is no way to guarantee that you will get true parallelism.

On the Java side, no. Java has zero control over this. It is up to the operating system scheduler.

At the container level, with 500 millicores you should¹ get at least 1/2 a core on average. However, at some times no cores will be allocated, and other times two or more cores could be allocated.

Also, if the node is not busy you may get more than 1/2 core on average. The OpenShift documentation says this:

"The CPU request represents a minimum amount of CPU that your container may consume, but if there is no contention for CPU, it can use all available CPU on the node. If there is CPU contention on the node, CPU requests provide a relative weight across all containers on the system for how much CPU time the container may use."

So, in practice, with 500 millicores there are no guarantees of true parallelism either.

However, even if you did get true parallelism with two threads, with 500 millicores you can only expect it 1/4 of the time. If your goal is to get reliably fast performance, you need multiples of cores. (You get what you pay for.)

---

^{1 - Note: you should get this. However, if the node's resources are over-committed, it is possible that you can get less CPU than you should.}