ONTOTEXT ANSWER:
This error is relatively common. This is a guard functionality of GraphDB. It is intended to prevent Out of Memory (OOM) exceptions. When evaluating “distinct”, the database has to keep a lot of data in memory. This is why it is being monitored. The easy way to fix the problem would be to give GraphDB more memory.
For details on what happens, read on.
This message gets triggered by queries with distinct and group by clauses. GraphDB has a few internal monitoring classes. One of these is intended for the size of the queries utilizing the “distinct” clause.
A simple query with distinct and Group by
What the monitor does is a very basic check. There is a threshold value. This value is calculated by summing a hard limit, 250 MB by default, and an estimate of the current memory allocated to processing other queries with the “distinct” keyword. If the currently available free memory is lower than this sum, the query is rejected. Here are a few examples:
- 249 MB free, 250 MB threshold, 0 MB already processing -> query is rejected.
- 259 MB free, 250 MB threshold, 10 MB already processing -> query is rejected.
- 260 MB free, 250 MB threshold, 10 MB already processing -> query is accepted.
So, the easy and “correct” solution would be to add extra memory to GraphDB and/or not run a lot of operations at the same time. In particular, queries with “distinct” and “group by” may lead to throttling other similar queries.
Another approach is to tweak the limit. The limit is configured via the default.min.distinct.threshold GraphDB property. By setting it to 0 – or a negative value – you are only comparing the free memory usage to the estimate of what’s already required for processing other queries with “distinct”. However, be warned that this is risking OOM errors due to lots of “distinct” queries happening at the same time.
Did this help you solve your issue? Your opinion is important not only to us but also to your peers.
Share this article
