Akka - during load testing forkjoinpool.scan at 20% of the processor time

We have made significant progress in load testing and scaling of the akka application, but we see scala.concurrent.forkjoin.ForkJoinPool.scan (), which appears as the second highest access point for about 20% of the battery life in VisualVM. The Self time column (CPU) says only part of this (less than 1% of the self time column value).

I suspect that this means blocking or context switching is potentially problematic, but I'm not sure: can anyone give an idea? If this is a context switch, then I assume that setting the dispatcher's bandwidth to a larger number can lead to increased profits, otherwise, if it is caused by a lock, we will need to read a little more code.

Any insight is greatly appreciated.

+6
source share
1 answer

The scan method also contains inactive threads in the ForkJoinPool "parks" when they cannot find work.

If 20% of the battery life and 1% of what the CPU time is, makes me think that you have inactive threads in ForkJoinPool that parked there.

I assume that you are using VisualVM in sample mode. By default, VisualVM filters information in the standard library. See this answer for how to change the settings and get a better idea of ​​what is happening. fooobar.com/questions/686362 / ...

+9
source

Source: https://habr.com/ru/post/955152/


All Articles