Error message while multithreaded solving

[Frank Förster]

Hi Optaplanner folks,

I have a problem when trying to solve a solution with many planning entites.
The solution contains about 1500 planning entites in a time line, but only around 20 are plannable, all others are pinned but I need them for the constraint checks. Periodically I move the "time window" of the unpinned entites via problem fact change.
In the log I get the following messages:
ERROR o.o.c.impl.solver.thread.ThreadUtils - Multithreaded Local Search's ExecutorService didn't terminate within timeout (1 seconds).
INFO  o.o.c.i.h.thread.MoveThreadRunner - Score calculation speed will be too low because move thread (0)'s destroy wasn't processed soon enough.
...
INFO  o.o.c.i.h.thread.MoveThreadRunner - Score calculation speed will be too low because move thread (9)'s destroy wasn't processed soon enough.

and the solver works very very slow.
If I reduce the amount of (pinned) entries, the solver works fine. Unfortunately I can't find any forum article or something like that when I seach for this message. Can anybody give me a hint how to fix this problem?

Thanks in advance,
Frank

[Lukas Petrovicky]

On Tue, Jun 1, 2021 at 8:56 AM Frank Förster <fft...@gmail.com> wrote:

If I reduce the amount of (pinned) entries, the solver works fine. Unfortunately I can't find any forum article or something like that when I seach for this message. Can anybody give me a hint how to fix this problem?

Without seeing the code, I can only make some very generic suggestions.

- Check your constraints. Are they performing poorly? You may find this interesting:

https://www.optaplanner.org/blog/2021/05/25/WritingFastConstraintStreamsSecretRecipe.html

- Check your <moveThreadCount>. Anything more than 4 will just cause slowdowns, we unfortunately do not scale well to more than 4.

- Check your memory use. GC can slow down your solver quite a lot, especially if it's running out of memory. And the likelihood of running out of memory grows also with a growing move thread count.

Regards!

--

Lukáš Petrovický

He/Him/His

Principal Software Engineer, Business Automation

Red Hat Czech, s. r. o.

lukas.pe...@redhat.com    IM: triceo/lpetrovi

[Frank Förster]

Hi Lukáš,

thanks for your help.

I will investigate your tipps. Currently using moveThreadCount=AUTO, may be that is the problem...

KR,

Frank

[Lukas Petrovicky]

On Tue, Jun 8, 2021 at 10:46 AM Frank Förster <fft...@gmail.com> wrote:

I will investigate your tipps. Currently using moveThreadCount=AUTO, may be that is the problem...

Assuming you have a lot of CPU cores, this is definitely a problem. We have a task out there to limit AUTO to 4 cores, because we simply don't scale well beyond that.