Question

我正在使用Optaplanner来解决相对较小的优化问题。对于我的用例，需要许多这样的优化，这就是我开始并行运行它们的原因。并行性基于Java 8＆＃39; GET: /logs/table/{tableName}?startTime=<>&endTime=<>。它不允许控制要使用的实际线程数，但我认为它基于可用的CPU数量。

对于大多数求解器运行来说，这似乎工作正常，但我注意到我有时从单次运行中得到无效的解决方案，只有当问题单独运行时才能重现。

检查完日志后，我注意到＆＃34;平均每秒计算次数＆＃34;对于无效解决方案来说非常低，而对于其他运行则很好。事实上，无效的解决方案实际上是（天真建立的）初始解决方案：

parallel stream

注意线程4和7如何产生25-30k accs的良好结果，而线程5产生无效结果并且仅使用4个accs（给定200ms终止超时我假设实际上只采取了一步）。

使用以下配置，使用基准测试程序确定（尽管在单线程设置中）：

[rkJoinPool.commonPool-worker-6] (DefaultSolver.java:203)       Solving started: time spent (0), best score (-5hard/-2medium/168soft), environment mode (REPRODUCIBLE), random (JDK with seed 0).
[rkJoinPool.commonPool-worker-6] (DefaultConstructionHeuristicPhase.java:158) Construction Heuristic phase (0) ended: step total (0), time spent (1), best score (-5hard/-2medium/233soft).
[rkJoinPool.commonPool-worker-4] (DefaultSolver.java:203)       Solving started: time spent (1), best score (-5hard/-1medium/579soft), environment mode (REPRODUCIBLE), random (JDK with seed 0). 
[rkJoinPool.commonPool-worker-4] (DefaultConstructionHeuristicPhase.java:158) Construction Heuristic phase (0) ended: step total (0), time spent (1), best score (-5hard/-1medium/617soft).
[rkJoinPool.commonPool-worker-5] (DefaultSolver.java:203)       Solving started: time spent (1), best score (-6hard/-3medium/137soft), environment mode (REPRODUCIBLE), random (JDK with seed 0).
[rkJoinPool.commonPool-worker-7] (DefaultLocalSearchPhase.java:152) Local Search phase (1) ended: step total (42), time spent (704), best score (0hard/0medium/808soft).
[rkJoinPool.commonPool-worker-4] (DefaultLocalSearchPhase.java:152) Local Search phase (1) ended: step total (22), time spent (218), best score (0hard/0medium/1033soft). 
[rkJoinPool.commonPool-worker-5] (DefaultSolver.java:238)       Solving ended: time spent (210), best score (-6hard/-3medium/137soft), average calculate count per second (4), environment mode (REPRODUCIBLE).
[rkJoinPool.commonPool-worker-7] (DefaultSolver.java:238)       Solving ended: time spent (746), best score (0hard/0medium/808soft), average calculate count per second (25256), environment mode (REPRODUCIBLE).
[rkJoinPool.commonPool-worker-4] (DefaultSolver.java:238)       Solving ended: time spent (219), best score (0hard/0medium/1033soft), average calculate count per second (30461), environment mode (REPRODUCIBLE).

我认为这个问题与几个求解器并行运行这一事实有关，而使用了基于时间的终止标准。终止时间是否基于＆＃34;挂起时间＆＃34;还是实际的CPU时间？

并行运行时使用基于时间的终止条件并不是一个好主意吗？这似乎是使用所有可用计算能力的最佳方式。什么可能导致单个求解器看似随意只执行这么少的步骤？

Answer 1

millisecondsSpentLimit和unimprovedMillisecondsSpentLimit基于待机时间，而非实际CPU时间。

AFAIK，并行流不会将线程数限制为CPU的数量，因为这些作业可能会在IO下阻塞（Solver.solve()调用不是这种情况）。我更喜欢使用线程池大小为ExecutorService的{{1}}。

Optaplanner：随机非常低＆＃34;每秒平均钙化计数＆＃34;在并行解决时

1 个答案: