Запросы GraphDB не выполняются автоматически (OutOfMemoryError) - PullRequest
Новая
       6

Запросы GraphDB не выполняются автоматически (OutOfMemoryError)

0 голосов
/ 09 мая 2018

Я имею дело с довольно большим репозиторием (то есть ~ 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

до заключения.

Обновление:

Здесь - основной журнал, описывающий проблему. Выходные данные в рабочей среде GraphDB:

Нет результатов. Запрос занял 1 м 53 с, минуты назад.

Нет упоминаний об ошибках. Довольно странно. Как указал Жиль-Антуан Найс, это проблема с памятью и GC Java. В целом, я думаю, что в таких случаях рабочая среда должна явно показывать сообщение об ошибке.

Ответы [ 2 ]

0 голосов
/ 26 мая 2018

Как уже говорилось в других комментариях, ошибка вызвана OME. В следующем выпуске GraphDB 8.6 разработчики реализовали гораздо более эффективную реализацию памяти для всех агрегатов и отдельных элементов. До его публичного выпуска есть только несколько вариантов для тестирования:

  1. Уменьшите объем используемой памяти, написав чуть более оптимальную версию вашего запроса, которая отображает только локальные имена: 
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)

  1. Увеличение доступной оперативной памяти для выполнения всех совокупных вычислений. Вы можете увеличить его, передав более высокое значение параметра -Xmx или установив минимальное число для graphdb.page.cache.size в файле graphdb.properties, например: graphdb.page.cache.size=100M. Кеш контролирует количество страниц, хранящихся в памяти, что для вашего запроса и размера хранилища не будет иметь большого значения.

  2. Ограничить максимальную длину строки объединения групп с помощью -Dgraphdb.engine.function.concat.max-length=4096. Предел не заставит запрос успешно выполняться, но он укажет, является ли проблема слишком большим количеством субъектов, слишком длинные строки.

0 голосов
/ 09 мая 2018

Во-первых, ваш запрос не может дать вам класс, который может быть определен типами ... Я рекомендовал добавить ?s в ваш select для выразительности. Так что вы можете легко ответить на ваш вопрос.

Вот самый простой запрос для него: 

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% памяти все еще используется).

Одним из решений является увеличение предела накладных расходов ГХ, что позволяет работать с вашим огромным набором данных.

...