使用JAVA异步运行gremlin查询时出现OOM错误

使用JAVA异步运行gremlin查询时出现OOM错误,java,out-of-memory,gremlin,janusgraph,tinkerpop3,Java,Out Of Memory,Gremlin,Janusgraph,Tinkerpop3,我们已经创建了一个restapi,它在Janus图上执行gremlin查询,并以JSON格式返回结果。API可用于小结果集的文件。但是对于大型结果集,当我们异步命中API时,它会给出以下错误,(max heap size-Xmx4g java.lang.OutOfMemoryError:超出GC开销限制 我正在使用curl和&异步命中API curl --location --request GET 'http://HOST:PORT/graph/search?gremlin=query &am

我们已经创建了一个restapi,它在Janus图上执行gremlin查询,并以JSON格式返回结果。API可用于小结果集的文件。但是对于大型结果集,当我们异步命中API时,它会给出以下错误,(max heap size
-Xmx4g

java.lang.OutOfMemoryError:超出GC开销限制

我正在使用curl和
&
异步命中API

curl --location --request GET 'http://HOST:PORT/graph/search?gremlin=query &
curl --location --request GET 'http://HOST:PORT/graph/search?gremlin=query &
curl --location --request GET 'http://HOST:PORT/graph/search?gremlin=query &
curl --location --request GET 'http://HOST:PORT/graph/search?gremlin=query &
连接到janus graph的代码

cluster = Cluster.open(config);
connect = cluster.connect();

submit = connect.submit(gremlin);
Iterator<Result> resultIterator = submit.iterator();
int count=0;
while (resultIterator.hasNext()){
    //add to list, commented to check OOM error
}
小精灵司机

org.apache.tinkerpop.gremlin-driver:3.4.6
如何像光标一样处理大型结果集,以便不是所有数据都加载到内存中?
是否有我缺少的配置?非常感谢您的帮助

小精灵查询:

g.withSack(0).V().hasLabel(%27material%27).has(%27dim_batchid%27,within(5028245,5080395,5366265,5159380,4872924,5093856,5216023,5068771,5093820,5154387,4703406,4872835,5214752,4893085,4866319,4556751,5342365,5075448,5074467,4835525,4987972,5347712,4986643,5204689,4755232,5076490,5028246,4922387,4659627,4597456,4743346,5080956,5370167,5260125,5134845,4613324,4720631,4937766,5356972,5148510,5210986,4930135,4984021,4720172,5028031,4836893,5068621,5333830,5020806,5081693,4988567,4869467,4709219,4958246,5021639,4607913,4923487,4614485,5066054,4869093,5339365,5204715,4980349,5215913,5342616,4959705,4959549,4929369,5022805,4920163,5204563,5027627,5208788,4712451,4862298,5019103,4982159,4727160,5395618,4924536,5390450,4943986,5071744,5208844,4898192,5347546,5204875,4710474,4794222,4962808,5269053,4836267,4602886,5359126,5393203,4780380,5148475,5092749,5351705,5339311,4601782,4869039,5366475,4959070,4963475,5346888,4923494,5279816,5297980,5154181,5030501,5142954,5392329,4839306,4890656,5134911,4893104,4989444,5069672,4961009,5027559,5029007,5285813,4820025,5287707,4959634,5148474,5362926,5362211,4557278,5353486,4933573,4785560,4890658,4930937,4553089,5030503,5341503,4783801,5068529,4821152,5208845,4766406,5043752,4770709,4733416,5204713,4815450,4981053,4963427,4980830,5340154,4771353,5204561,4920161,4794149,5275867,5021788,5364102,5205411,5356459,4794233,4923438,4610509,5392350,4746342,5022804,4936411,5361555,4890888,4980829,4959869,4869092,4891157,4815449,5267434,4836975,4684010,5281322,5071746,4711290,5289333,5021638,5299283,5210803,5348731,5068491,4776862,5196532,4766677,4930133,5210984,4608878,5261295,4826630,4786051,4779996,4930134,5020804,4766678,4869064,5286802,4545299,4693065,4930844,4816538,4888415,4711706,4923002,4780402,5044968,5148437,4753993,5074466,4890805,5074558,5076491,4547035,5092021,5262308,5205445,5213382,5159381,5263280,5351407,4890706,4659738,5344469,5075928,4613336,5065866,4863764,5217111,4792255,5210914,5204691,4890806,5148438,4986897,4817686,4712337,5196528,5280266,4929327,5134843,5393007,5019151,4923482,4763007,4929395)).emit().repeat(sack(sum).by(constant(1)).inE().outV()).project(%27level%27,%27properties%27).by(sack()).by(tree().by(valueMap().by(fold().unfold())).by(valueMap().by(fold())))
从分析中,很明显是gremlin驱动程序导致了这个问题,但我不确定如何修复它并释放内存。

此外,线程进入冻结状态超过5分钟


我认为您可能遇到了这个问题。基本上,保存传入结果的队列的填充速度比您使用结果的速度快,并且您的堆被破坏了。您可以看到,在这个问题中有一个补丁似乎解决了问题,但我不相信这是最好的解决方案et,因此它尚未实施。如果您对如何解决问题有任何建议,请随时对问题进行评论。如果这不是您面临的问题,我认为您必须提供一种方法来复制您的问题或进行一些分析,以进一步隔离您的问题。也许按照您的意愿进行一些分析会很好我可以用这种方式证明TINKERPOP-2424是您的问题。如果您看了那篇文章中的,您应该会看到验证问题所采取的方法。

Gremlin服务器是否生成OOM或您的REST API?此外,它看起来像您提交了一个Gremlin脚本-您可能需要共享该查询。REST API在命中时导致OOMAPI是异步的。问题在这里
while(resultIterator.hasNext())
。查询返回一个大数据集,导致它等待所有结果完成。@stephenmallette我已在问题中添加了查询。该循环中的注释为“//add to list,commented to check error”-你真的在用每个结果构建一个
列表
对象吗?我在构建,但注释了该代码,以检查添加到列表是否导致OOM,但事实并非如此。感谢你的回答。我已经完成了分析,似乎问题出在gremlin驱动程序上。我已经添加了分析的屏幕截图。我认为这与QE无关在我的测试中,我发现仅仅在没有处理结果的情况下进行迭代并没有足够快地清空队列以使GC跟上。这有点奇怪-直到我亲眼看到才相信这一点。只有在异步运行查询时才出现问题它适用于单个查询执行。但即使对于单个查询,它也不会释放所有堆内存。
g.withSack(0).V().hasLabel(%27material%27).has(%27dim_batchid%27,within(5028245,5080395,5366265,5159380,4872924,5093856,5216023,5068771,5093820,5154387,4703406,4872835,5214752,4893085,4866319,4556751,5342365,5075448,5074467,4835525,4987972,5347712,4986643,5204689,4755232,5076490,5028246,4922387,4659627,4597456,4743346,5080956,5370167,5260125,5134845,4613324,4720631,4937766,5356972,5148510,5210986,4930135,4984021,4720172,5028031,4836893,5068621,5333830,5020806,5081693,4988567,4869467,4709219,4958246,5021639,4607913,4923487,4614485,5066054,4869093,5339365,5204715,4980349,5215913,5342616,4959705,4959549,4929369,5022805,4920163,5204563,5027627,5208788,4712451,4862298,5019103,4982159,4727160,5395618,4924536,5390450,4943986,5071744,5208844,4898192,5347546,5204875,4710474,4794222,4962808,5269053,4836267,4602886,5359126,5393203,4780380,5148475,5092749,5351705,5339311,4601782,4869039,5366475,4959070,4963475,5346888,4923494,5279816,5297980,5154181,5030501,5142954,5392329,4839306,4890656,5134911,4893104,4989444,5069672,4961009,5027559,5029007,5285813,4820025,5287707,4959634,5148474,5362926,5362211,4557278,5353486,4933573,4785560,4890658,4930937,4553089,5030503,5341503,4783801,5068529,4821152,5208845,4766406,5043752,4770709,4733416,5204713,4815450,4981053,4963427,4980830,5340154,4771353,5204561,4920161,4794149,5275867,5021788,5364102,5205411,5356459,4794233,4923438,4610509,5392350,4746342,5022804,4936411,5361555,4890888,4980829,4959869,4869092,4891157,4815449,5267434,4836975,4684010,5281322,5071746,4711290,5289333,5021638,5299283,5210803,5348731,5068491,4776862,5196532,4766677,4930133,5210984,4608878,5261295,4826630,4786051,4779996,4930134,5020804,4766678,4869064,5286802,4545299,4693065,4930844,4816538,4888415,4711706,4923002,4780402,5044968,5148437,4753993,5074466,4890805,5074558,5076491,4547035,5092021,5262308,5205445,5213382,5159381,5263280,5351407,4890706,4659738,5344469,5075928,4613336,5065866,4863764,5217111,4792255,5210914,5204691,4890806,5148438,4986897,4817686,4712337,5196528,5280266,4929327,5134843,5393007,5019151,4923482,4763007,4929395)).emit().repeat(sack(sum).by(constant(1)).inE().outV()).project(%27level%27,%27properties%27).by(sack()).by(tree().by(valueMap().by(fold().unfold())).by(valueMap().by(fold())))