Hi all, I just want to reopen the question asked in this previous related issue : As we are suggesting in pyrdf2vec to setup a local SPARQL endpoint using Stardog, several people might have to deal with this related issue (crf. this blogpost ). Currently, we make simple select requests to our local…

OK, I think I have reproduced the problem. The issue is pretty specific, it requires some extremely fast queries coming with high degree of concurrency so that the queries would run faster than a background thread to perform one particular kind of cleanup. I will create a ticket about it. As a work…

Hi Bram, Can you collect the heap dump when the server runs out of memory (using -XX:+HeapDumpOnOutOfMemoryError) and share with us? You can run the server with less heap so the dump is smaller and the OOM happens faster. You can put it up somewhere like Dropbox or Google Drive. Also couple of que…

Hi Pavel, Thanks for your quick reply. I'm using Stardog 7.4.5 It might indeed be a problem that our client does not properly close the connection. We are using the faster_than_request python library to make these requests, and i'm not sure if they handle this properly.. I have now switched to …

So I changed some of our application code to pystardog, to make sure the connections are closed. The OOM issue might be resolved now (not sure, still testing) but I still notice a large decay in query performance: With a fresh restarted server Backup Storage Directory : .backup CPU Load …

That's interesting. The database is not being updated, right? I'd suggest printing GC info and if you see that GC activity increases over time, share heap dumps with us. Best, Pavel

Hi Pavel, No updates, just select queries. dump.hprof.gz Google Drive file. Kind regards, Bram

I don't really see any evidence of leaks or GC related issues in this heap. Strongly reachable objects are like 2.5Gb only so there's a lot of room to play with. Do you see increased GC activity when running your test? If not, but queries still get slower, we'll need to resort to profiling (I perso…

I suspect I had an OOM last night: https://drive.google.com/file/d/18wU8qWKEgjkBk8Ad-VDG4w2Z6O9LHbnX/view?usp=sharing java.lang.OutOfMemoryError: GC overhead limit exceeded Dumping heap to java_pid12785.hprof ... Heap dump file created [30495245066 bytes in 114.905 secs] WARN 2021-05-06 18:17:53,…

Yes, this is an OOM for sure. Let's do one of the following: reproduce the same on a smaller heap (let's say up to 8G) so it's easier for us to analyse. I don't see why that use case would need so much heap. provide the scripts to reproduce the issue on our side Reproducing with 7.6.2 (or 7.6.3 w…

Hi Pavel, A new OOM with Stardog 7.6.2 (smaller heap size): java_pid23297.hprof.gz Google Drive file. I have also added the script which causes this OOM crash bench_star.py.txt (11.0 KB) Kind regards, and thanks in advance, Bram

Thanks, this is useful. There's definitely a problem with queries not properly terminated and GC'd thus accumulating on the heap but we need to look a little deeper into it. Best, Pavel

“GC overhead limit exceeded” DBPedia sparql endpoint

Support

bsteenwi (Bram Steenwinckel) May 10, 2021, 4:35pm 16

No, two separate nodes.

(so not related to this issue anymore)

Topic		Replies	Views
Query timeouts and killing fails Support	4	1617	February 17, 2017
Full CPU usage when doing nothing Bug	5	1354	September 11, 2018
Stardog is running out of RAM with 16GB RAM and 15 millions triples Bug	3	884	March 18, 2020
Deal withh "GC overhead limit exceeded" when setup a local sparql endpoint Support	9	441	January 19, 2021
java.lang.OutOfMemoryError: Java heap space Support	18	3153	April 28, 2017

“GC overhead limit exceeded” DBPedia sparql endpoint

Related topics