Hi, I'm referring to a query like this, based on the Wikidata cats example:
SELECT ?item WHERE { ?item wdt:P31 wd:Q146 . ?crash rdfs:label ?_crashLabel }
on my local Blazegraph, I can see that it uses up all the CPU cores and goes up in RAM, and eventually kills the query with: Caused by: com.bigdata.rwstore.sector.MemoryManagerOutOfMemory at com.bigdata.rwstore.sector.MemoryManager.getSectorFromFreeList(MemoryManager.java:646)
Could Blazegraph prevent this query from even starting? Thanks!
Cheers Miguel
Hi!
On 4/24/17 5:28 AM, Miguel Paraz wrote:
Hi, I'm referring to a query like this, based on the Wikidata cats example:
SELECT ?item WHERE { ?item wdt:P31 wd:Q146 . ?crash rdfs:label ?_crashLabel }
I think you misunderstand the query. What this query says is: Give me all bindings where ?item is part of triple such that it has predicate wdt:P31 and object wd:Q146, and ?crash and ?_crashLabel are such that they are linked by rdfs:label predicate. The latter probably has a lot of bindings if you have loaded wikidata dump, since the data has a lot of triples with predicate rdfs:label. So while trying to process all these bindings, you get OOM.
In general, I'd recommend always putting limit on a query when you're trying to compose it. If you don't need it, remove it as the last step, but until you're sure your query means what you think it means, use limit, it'll save you time and frustration and CPU resources :)
Could Blazegraph prevent this query from even starting?
There's no reason to prevent this query from starting, it's a completely legitimate query, just most likely not doing what you thought it's doing.
wikidata-tech@lists.wikimedia.org