我写了一个paralellized alghoritm来完成对Orient表中存储的数据的计算。
为了控制内存,我尝试对这些数据进行分页,并尝试将我的alghoritm并行化,以提高性能(使用Future任务)。
我的东方设置是:
set ORIENTDB_SETTINGS=-Dprofiler.enabled=true -Dstorage.diskCache.bufferSize=12906
set JAVA_OPTS_SCRIPT=-Xmx4096M -Djna.nosys=true -XX:+HeapDumpOnOutOfMemoryError -XX:PermSize=1024m
-XX:MaxPermSize=1024m
-Djava.awt.headless=true -Dfile.encoding=UTF8 -Drhino.opt.level=9
-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005
Xmx修复为4 GB(4096MB作为上层配置),我试图用JVisualVM监控我的Orient过程,如下面的截图:
在JVIsualVm进程中,堆内存总是在其限制之下,但在Windows进程列表中,相同的进程(我突出显示了PID)占用7 GB并且总是增长。
这是我的代码:
for (Callable worker : workers) {
Future<Boolean> submit = executor.submit(worker);
futures.add(submit);
}
workers.clear();
workers = null;
boolean success = true;
for (Future<Boolean> future : futures) {
try {
if (Boolean.TRUE.equals(future.get())) {
[CODE BLOCK]
} else {
[CODE BLOCK FOR REPROCESS FUTURE]
}
} catch (InterruptedException e) {
e.printStackTrace();
} catch (ExecutionException e) {
e.printStackTrace();
}
}
答案 0 :(得分:1)
根据你的图片,进程已消耗7GB内存,根据你允许使用的设置-Dstorage.diskCache.bufferSize=12906
消耗少于13GB的内存。如果您希望处理消耗较少的内存,则应更改设置中消耗内存的最大限制。磁盘缓存永远不会释放内存,以便为最广泛的查询实现最短的查询响应时间。