内存泄漏或拥挤的工人使用修改后的DeepLearning4Java（使用akka）

Question

我正在使用DeepLearning4Java的修改版本来使用UIMA CollectionReader处理文档。对于大型文档集合，我遇到了GC Overhead Limit Error或不同类型的TimeOut错误（例如，线程中的异常＆＃34; RMI TCP连接（空闲）＆＃34;）因为垃圾收集花费的时间更多。我不确定它是否是内存泄漏，或者我只是在工作邮箱中堆积太多工作。我不熟悉scala和akka，这对我们没有帮助。

我的应用程序运行正常，直到它接近堆限制（尝试使用4GB和8GB），然后在达到GC开销限制之前减速。这不是PermGen空间使用永远不会超过45 MB的问题，也不是创建太多类的问题 - 我只看到大约7000个加载，它在运行时基本上是完全平坦的。

主要罪魁祸首可以在下面的截图中看到。

使用vocabActor.tell在org.deeplearning4j.bagofwords.vectorizer.BaseTextVectorizer中实例化这些对象。

while(docIter != null && docIter.hasNext()) {

            vocabActor.tell(new StreamWork(new DefaultInputStreamCreator(docIter),latch),vocabActor);

            queued.incrementAndGet();
            if(queued.get() % 10000 == 0) {
                log.info("Sent " + queued);
                try {
                    Thread.sleep(1);
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            }

        }

我理解的tell函数是akka中的scala代码

  final def tell(msg: Any, sender: ActorRef): Unit = this.!(msg)(sender)

我的理解是，这将进入工作人员的邮箱以等待处理 - 但我认为一旦处理完工作，所有对此的引用都将消失。所以我不确定为什么这么多对象都存在，必须有一些钩子阻止GC摧毁这些对象 - 也许是因为它们在邮箱中并且还没有被处理过？循环可以运行一段时间，但我会假设所有StreamWork对象都被回收。

我的问题是，是否有办法弄清楚我是否需​​要切换到不同类型的调度程序以某种方式限制消息生成或我是否应该查看内存泄漏。如果需要，我可以发布DocumentIterator或其他代码。

Answer 1

请始终使用Maven Central提供的最新dl4j / nd4j版本。 你说的那个错误已经修复了一段时间了，Akka已经不再使用了。

P.S。最新版本目前为0.4-rc3.8。