Java OutOfMemoryError with Sesame

Question

Я использую Sesame для запроса RDF через SPARQL. Я работаю с большими файлами (2 ГБ, 10 ГБ) и потом выполняю несколько запросов. Во время работы с такими большими файлами я получаю сообщение об ошибке java.lang.OutOfMemoryError: Java heap space. Я запускаю свое приложение с параметром -Xmx3g, но похоже, этого недостаточно для этих файлов. Может быть, я должен закрыть репозиторий после каждого запроса?

Существует мой код:

void runQuery() { 
    try { 
     con = repo.getConnection(); 
     TupleQuery tupleQuery = con.prepareTupleQuery(QueryLanguage.SPARQL, queryString); 
     TupleQueryResult result = tupleQuery.evaluate(); 
     while (result.hasNext()) { 
      result.next(); 
     } 
     result.close(); 
     con.close(); 
     } catch (Exception e) { 
      ... 
     } 
    } 
} 

runTests() { 
    File dataDir = new File("RepoDir/"); 
    repo = new SailRepository(new NativeStore(dataDir)); 
    repo.initialize(); 
    ... 
    for (int j = 0; j < NUMBER_OF_QUERIES; ++j) { 
     queryString = queries.get(j); 
     runQuery(); 
    } 
    ... 
    repo.shutDown(); 
} 

Кроме того, можно использовать MemoryStore вместо NativeStore для таких больших файлов?

Пример запроса, который излучает ошибку:

SELECT DISTINCT ?name1 ?name2 
WHERE { 
    ?article1 rdf:type bench:Article . 
    ?article2 rdf:type bench:Article . 
    ?article1 dc:creator ?author1 . 
    ?author1 foaf:name ?name1 . 
    ?article2 dc:creator ?author2 . 
    ?author2 foaf:name ?name2 . 
    ?article1 swrc:journal ?journal . 
    ?article2 swrc:journal ?journal 
    FILTER (?name1<?name2) 
} 

Answer 1

Так вот SP2B Query 4 (информация, которая была бы полезно, чтобы обеспечить в исходном сообщении, пожалуйста, через ваши вопросы, если вы ожидаете, что люди будьте осторожны с их ответами).

SP2B Query 4 на шкале 5M возвращает результаты ~ 18.4M. Набор данных 5M (в черепахе) составляет ~ 500M, поэтому, учитывая ваши заявленные размеры, я предполагаю, что вы пытаетесь это с наборами данных 25M и 100M?

original authors даже не смогли опубликовать размер результирующего набора для Q4, поскольку ничто не могло его вычислить (по крайней мере, с учетом результатов исследования). Учитывая масштабный коэффициент, очевидный в наборе данных для результатов этого запроса, я бы предположил, что мы берем около 100 м + результатов в масштабе 25М и, возможно, до 1В результатов в масштабе 100М.

Размер промежуточных соединений, необходимых для расчета набора результатов, который имеет размер , огромный, и его неудивительно, что 3G ОЗУ недостаточно. Кунжут - хорошая система, но я не знаю, сколько памяти потребуется для ответа на этот запрос в этом масштабе или даже если бы он мог ответить на него вообще.

Насколько мне известно, только одна система сообщила о запуске этого запроса на 25M, и никто не запустил его на 100M. Вот почему SP2B - отличный, но извращенный показатель. Вы можете прочитать немного больше материала на нем, а также взглянуть на BSBM, если вы пытаетесь выполнить бенчмаркинг производительности трех магазинов.