GraphDB 查询静默失败 (OutOfMemoryError)答案

【问题标题】：GraphDB queries fail silently (OutOfMemoryError)GraphDB 查询静默失败 (OutOfMemoryError)
【发布时间】：2018-05-09 12:33:39
【问题描述】：

我正在处理一个非常大的存储库（即~16M 语句）。我试图在我的图表中获取所有不同类成员模式的列表。这是查询：

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

select distinct (group_concat(?t) as ?fo)
where { 
    ?s rdf:type ?t.    
} 

group by (?s)
order by ?fo

当然，这样的查询确实必须返回结果。奇怪的是，有时我得到了我需要的结果，有时查询没有返回结果。

为什么会发生这种情况，我该如何避免？

PS：监控查询，发现当我没有数据时，查询状态一直卡在：

IN_HAS_NEXT

0 operations

直到结论。

更新：

Here 是描述问题的主要日志。 GraphDB 工作台中的输出为：

没有结果。几分钟前，查询耗时 1m 53s。

没有提及错误。很奇怪。正如 Gilles-Antoine Nys 所指出的，这是内存和 Java GC 的问题。总的来说，我认为工作台在这种情况下应该明确显示错误消息。

【问题讨论】：

标签： sparql graphdb

【解决方案1】：

首先，您的查询无法为您提供可以由类型定义的类...我重新开始在您的 select 中添加 ?s 以提高表达能力。这样您就可以轻松回答您的问题了。

这是最简单的查询：

select ?s (group_concat(?t) as ?fo)
where { 
?s rdf:type ?t.    
} group by (?s)

（如果对您很重要，可以添加order by(?fo)）。

其次，IN_HAS_NEXT 只是您在监视器中暂停查询时的一种状态。与错误无关。

最后，验证您的 query-timeout 参数。它的默认值设置为 0。

更新：

实际上，您的日志文件中有两个错误。问题是您的 JVM 占用您的内存的时间太长（超过 98% 的内存仍在使用中）。

一种解决方案是增加您的 GC 开销限制，因此可以处理您的庞大数据集。

【讨论】：

你好。我不明白您对查询的警告。我正在寻找所有不同类成员模式的列表（也许我必须在我的问题中更好地指定它）。无论如何，我没有暂停查询，似乎 GraphDB 遇到了一些执行问题，并且它们不系统。 PS：query-timeout 已经设置为 0。
您已经阅读了日志吗？ (..\AppData\Roaming\GraphDB\logs)
原帖中插入的日志。
知道了！你知道在 GraphDB 中处理这个问题的有效方法吗？
确实-XX:-UseGCOverheadLimit 是硬解。也许您可以尝试使用更多 RAM 的机器？不知道它是否可以改进处理，但以更“自然”的方式。

【解决方案2】：

正如其他 cmets 已经暗示的那样，该错误是由 OME 引起的。在下一个即将发布的 GraphDB 8.6 版本中，开发人员对所有聚合和区分实现了更高的内存效率。在公开发布之前，只有几个选项可供测试：

通过编写稍微更优化的查询版本来减少消耗的内存量，该版本仅显示本地名称：

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
select ?s_local (group_concat(?t_local) as ?fo)
where {
    ?s rdf:type ?t.
    BIND (REPLACE(STR(?t), "^(.*)(/|#)([^#/]*)$", "$3") as ?t_local)
    BIND (REPLACE(STR(?s), "^(.*)(/|#)([^#/]*)$", "$3") as ?s_local)
} group by (?s_local)
order by (?fo)

增加可用 RAM 以执行所有聚合计算。您可以通过传递-Xmx 参数的更高值或在graphdb.properties 中为graphdb.page.cache.size 设置最小数字来增加它，例如：graphdb.page.cache.size=100M。缓存控制存储在内存中的页面数量，这对于您的查询和存储库大小不会有太大影响。
用-Dgraphdb.engine.function.concat.max-length=4096 限制组连接字符串的最大长度。限制不会使查询成功执行，但它会指示问题是否是主题太多太长的字符串。

【讨论】：

【解决方案3】：

GraphDB Free 的问题是：它会随着工作台的调用而增加堆大小。例如，如果您查询或只是刷新工作台，您可能会看到堆大小增加。现在即使您确实有大量内存，随着堆大小的不断增加，连续查询更多的查询也会产生 OOM。解决方案可能是在每次调用时查找 GraphDB 存储的临时数据，这会增加堆大小。

【讨论】：