Hi Vince > JVM memory derived from container limits
What do you mean by this specifically? As has been discussed and referenced previously on this list, and is noted in our TDB FAQs [1], much of the memory usage for TDB databases is in terms of off-heap usage via memory mapped files. Therefore, setting the JVM heap too high can actually reduce performance as the JVM is then competing against the OS for memory and forcing the mapped files to be paged out reducing performance. So firstly, I’d make sure you aren’t setting the JVM heap to use too much of your available memory. Ensure you are leaving some headroom between JVM heap and container limits for OS usage for the memory mapped files. Since you mention you have Grafana in place I’d also look at any metrics that might be available around memory mapped file usage/paging etc. to see if this might be your problem. > The second query is memory-intensive Yes, operators like DISTINCT that require the query engine to keep large chunks of the data in-memory are always going to be memory-intensive. The Jena query engine is generally designed for lazy streaming and calculation of results as much as possible. If you have control over queries being issued then I would look at whether you actually need to be using operators like DISTINCT in your queries. > TDB optimizer, but that isn’t an option with our number of datasets and graphs, as far as we can tell Don’t really follow this statement. I assume you’re referring to the optional stats based optimiser? Unless your datasets are being frequently updated, I don’t see why you wouldn’t gain some value from generating the stats for each dataset. Remember that the TDB optimizer works on a per-dataset basis so you can generate stats files for each dataset, or some subset of your datasets, placing each stats file into the relevant database directory and they don’t interact with each other. > In production, we have multiple datasets consisting of millions of triples, and our end goal is to improve query times for our users. Often the best way to improve query times for users is either to exert more control over the queries (if the queries aren’t end-user controlled) using tools like Jena’s qparse [2] to analyse your queries and experiment with modifications to them that might optimise better. Or if you permit arbitrary queries to educate/train your users on best practises/how to write better queries/SPARQL optimisation etc. Another thing to consider is that if you aren’t doing federated queries across your multiple datasets you might actually be better off having independent smaller instances of Fuseki running on smaller AWS nodes, each serving a separate dataset. This would give you more flexibility to tune the resources, JVM heap etc. for each dataset depending on its needs. Hope this helps, Rob [1] https://jena.apache.org/documentation/tdb/faqs.html#java-heap [2] https://jena.apache.org/documentation/query/explain.html From: Vince Wouters via users <[email protected]> Date: Thursday, 15 January 2026 at 12:25 To: [email protected] <[email protected]> Cc: Vince Wouters <[email protected]> Subject: Increasing Apache Jena Performance Hello Jena community, We’re looking for guidance on what other avenues are worth exploring to improve overall query performance on our Apache Jena Fuseki instance, which consists of multiple datasets, each containing millions of triples. *Setup* - Apache Jena Fuseki *5.5.0* - TDB2-backed datasets - Running on *AWS EKS (Kubernetes)* - Dataset size: ~15.6 million triples *Infrastructure* - Instances tested: - *c5a.2xlarge* (16 GiB instance, 12 GiB pod memory) - *c5a.4xlarge* (32 GiB instance, 28 GiB pod memory) - JVM memory derived from container limits - Grafana metrics show no storage bottleneck (IOPS and throughput remain well within limits) *Test Queries* SELECT (COUNT(DISTINCT ?s) AS ?sCount) WHERE { GRAPH ?g { ?s ?p ?o } } Takes around 80 seconds for our dataset. SELECT (COUNT(DISTINCT CONCAT(STR(?s), STR(?p))) AS ?c) WHERE { GRAPH ?g { ?s ?p ?o } } Takes around 120 seconds for our dataset. *What we’ve observed* - The first query is stable once a minimum heap is available. - The second query is memory-intensive: - On the smaller instance, it will time out once available heap drops below a certain threshold. - On the larger instance we see clear improvements, but not linear scaling. - Increasing heap helps to a point, but does not feel like the full solution. *Other things we’ve tried* - TDB optimizer, but that isn’t an option with our number of datasets and graphs, as far as we can tell. *Question* Given this type of workload and dataset size, what other routes should we consider to improve performance, beyond simply adjusting heap size? In production, we have multiple datasets consisting of millions of triples, and our end goal is to improve query times for our users. Any guidance or pointers would be much appreciated. Thanks in advance.
