Thanks, Andy & Simon. I hadn't spotted the fan-out in the optionals.
Unfortunately, that's the part that varies a lot, and seems to be
machine-written, so it looks like I've got a painful time ahead of me rewriting
the automated query-writer. (I'm also going to recommend we try upgrading to
5.1, but that won't help with the bad queries).
Thanks,
Hugo.
Hugo Mills
Development Team Leader
agrimetrics.co.uk
Reading Enterprise Centre, Whiteknights Road, Reading, UK, RG6 6BU
-----Original Message-----
From: Andy Seaborne <a...@apache.org>
Sent: 09 September 2024 19:34
To: users@jena.apache.org
Subject: Re: Fuseki: Query timeouts not timing out
On 09/09/2024 15:49, Simon Bin wrote:
> The issue is probably that you are not nesting the optionals, i.e.
>
> OPTIONAL {
> ...
> OPTIONAL {
> ...
> OPTIONAL {
> ....
> }
> }
> }
>
> in other words you have to fix your queries
Running the example through qparse to get some formatting - see below.
No nested OPTIONALS.
Except the effect of
OPTIONAL
{ ?item def-ef:samplingPoint ?___5 .
?___5 spatialrelations:northing ?___4
}
...
OPTIONAL
{ ?___4 geo:lat ?___20 }
If the first has no results, the second could be a lot.
+ the other OPTIONAL not mentioning ?item.
There is quite a lot of possible fan-out duplication elsewhere as well.
And then
ORDER BY ...
OFFSET 0
LIMIT 25
all for:
SELECT DISTINCT ?item
so could be a lot going into the sort to just return ?item in a nice order. (I
bet other queries adjust the paging - get larger chunks (say, LIMIT 1000) and
mange in the UI.
Try this:
SELECT (count(*) AS ?C)
WHERE
{
...
}
## No ORDER BY, no LIMIT/OFFSET
Andy
PREFIX dgu: <http://reference.data.gov.uk/def/reference/>
PREFIX dct: <http://purl.org/dc/terms/>
PREFIX def-som: <http://environment.data.gov.uk/def/bwq-som/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX def-stp: <http://environment.data.gov.uk/def/bwq-stp/>
PREFIX def-bw: <http://environment.data.gov.uk/def/bathing-water/>
SELECT DISTINCT ?item
WHERE
{ { BIND(xsd:dateTime(replace(str(now()), "\\..*$", "")) AS ?doi)
{ ?som def-bw:bathingWater ?bwt ;
def-som:startOfSuspension ?start
FILTER NOT EXISTS { ?som dct:isReplacedBy ?som2 }
}
OPTIONAL
{ ?som def-som:endOfSuspension ?end }
BIND(?som AS ?item)
FILTER ( ( ( bound(?end) && ( ?start <= ?doi ) ) && ( ?doi <= ?end ) )
|| ( ( ! bound(?end) ) && ( ?start <= ?doi ) ) )
}
UNION
{ BIND(xsd:dateTime(replace(str(now()), "\\..*$", "")) AS ?doi)
?stp def-stp:riskLevel def-stp:increased ;
def-stp:bathingWater ?bwt ;
def-stp:publishedAt ?padt ;
def-stp:expiresAt ?end ;
def-stp:predictedAt ?start
FILTER ( ( ?start <= ?doi ) && ( ?doi <= ?end ) )
FILTER NOT EXISTS { ?stp2 def-stp:bathingWater ?bwt ;
def-stp:publishedAt ?padt2 ;
def-stp:expiresAt ?end2 ;
def-stp:predictedAt ?start2
FILTER ( ( ( ?padt2 > ?padt ) && ( ?start2 <= ?doi
) ) && ( ?doi <= ?end2 ) )
}
BIND(?stp AS ?item)
}
UNION
{ BIND(xsd:dateTime(replace(str(now()), "\\..*$", "")) AS ?doi)
{ ?pi rdf:type def-som:PollutionIncident ;
def-bw:bathingWater ?bwt ;
def-som:startOfIncident ?start
FILTER NOT EXISTS { ?pi dct:isReplacedBy ?other }
}
OPTIONAL
{ ?pi def-som:endOfIncident ?end }
FILTER ( ( ?start <= ?doi ) && ( ( ! bound(?end) ) || ( ?doi <= ?end )
) )
BIND(?pi AS ?item)
}
OPTIONAL
{ ?item def-stp:riskLevel ?___1 .
?___1 def-stp:riskNotation ?___0
}
OPTIONAL
{ ?item def-stp:samplingPoint ?___3 .
?___3 geo:long ?___2
}
OPTIONAL
{ ?item def-ef:samplingPoint ?___5 .
?___5 spatialrelations:northing ?___4
}
OPTIONAL
{ ?item dgu:uriSet ?___7 .
?___7 rdf:type ?___6
}
OPTIONAL
{ ?item def-bwq:sampleYear ?___9 .
?___9 skos:prefLabel ?___8
}
OPTIONAL
{ ?item def-stp:predictedAt ?___10 }
OPTIONAL
{ ?item def-bw:bathingWater ?___12 .
?___12 rdf:type ?___11
}
OPTIONAL
{ ?item def-som:incidentType ?___14 .
?___14 rdf:type ?___13
}
OPTIONAL
{ ?item def-som:notation ?___15 }
OPTIONAL
{ ?___2 spatialrelations:northing ?___16 }
OPTIONAL
{ ?item def-som:recordDateTime ?___17 }
OPTIONAL
{ ?item def-som:startOfIncident ?___18 }
OPTIONAL
{ ?item dct:description ?___19 }
OPTIONAL
{ ?___4 geo:lat ?___20 }
OPTIONAL
{ ?item def-som:nirsRef ?___21 }
}
ORDER BY ?___0 DESC(?___2) DESC(?___4) ?___6 ?___8 ?___10 DESC(?___11)
DESC(?___13) ?___15 ?___16 ?___17 ?___18 DESC(?___19) DESC(?___20)
DESC(?___21) ?item
OFFSET 0
LIMIT 25
>
> On Mon, 2024-09-09 at 14:10 +0000, Hugo Mills wrote:
>>
>>
>>
>> One addendum here:
>>
>> I can confirm that almost all of the problematic queries are of a
>> similar structure to the one I quoted here. They only differ in the
>> trailing OPTIONAL clauses. None of the non-problematic queries have
>> this structure.
>>
>> Hugo.
>>
>>
>>
>> Hugo Mills
>>
>> Development Team Leader
>>
>> agrimetrics.co.uk
>>
>> Reading Enterprise Centre, Whiteknights Road, Reading, UK, RG6 6BU
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> From: Hugo Mills <hugo.mi...@agrimetrics.co.uk>
>> Sent: 09 September 2024 11:12
>> To: users@jena.apache.org
>> Subject: RE: Fuseki: Query timeouts not timing out
>>
>>
>>
>> (Apologies if the quoting is broken here, I'm having to use Outlook
>> and do old-style quoting manually).
>>
>>
>> Hugo Mills
>>
>> Development Team Leader
>>
>> agrimetrics.co.uk
>>
>> Reading Enterprise Centre, Whiteknights Road, Reading, UK, RG6 6BU
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 08 September 2024 11:39, Andy Seaborne wrote:
>>> On 06/09/2024 16:23, Simon Bin wrote:
>>>> As far as I know, there have been some fixes to query time-outs in
>>>> the latest Jena versions.
>>>
>>> Yes - and the area has been rewritten.
>>>
>>> For this, and for the previous email, we need more information,
>>> otherwise all we > can do is speculate.
>>>
>>> + workload - query only or query + frequent updates?
>>
>> Mostly read queries. There are updates, but infrequent.
>>
>>> + example queries
>>
>> This is one of the ones that's been taking a long time:
>>
>> PREFIX xsd:
>> <http://www/
>> .w3.org%2F2001%2FXMLSchema%23&data=05%7C02%7CHugo.Mills%40agrimetrics
>> .co.uk%7C063d6218fe6c42e9f0fc08dcd0fe04cc%7C6ca596a570584494965cb808e
>> 7ab8057%7C1%7C0%7C638615036644241645%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
>> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%
>> 7C&sdata=nO%2B48bFyndHUVBaGMniMM77C%2Fb%2Bv9oPtYWU227v8XpA%3D&reserve
>> d=0> PREFIX skos:
>> <http://www/
>> .w3.org%2F2004%2F02%2Fskos%2Fcore%23&data=05%7C02%7CHugo.Mills%40agri
>> metrics.co.uk%7C063d6218fe6c42e9f0fc08dcd0fe04cc%7C6ca596a57058449496
>> 5cb808e7ab8057%7C1%7C0%7C638615036644245315%7CUnknown%7CTWFpbGZsb3d8e
>> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0
>> %7C%7C%7C&sdata=ucww%2BklGm02iNCcX9CCM6nwXvfCfB5jXMteu4nDJYEY%3D&rese
>> rved=0>
>> PREFIX spatialrelations:
>> <http://dat/
>> a.ordnancesurvey.co.uk%2Fontology%2Fspatialrelations%2F&data=05%7C02%
>> 7CHugo.Mills%40agrimetrics.co.uk%7C063d6218fe6c42e9f0fc08dcd0fe04cc%7
>> C6ca596a570584494965cb808e7ab8057%7C1%7C0%7C638615036644249875%7CUnkn
>> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
>> iLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=tmOQvG7yQB9WmY9YH0IlGxb2ERHfjDHiYo
>> xCuTw7UCM%3D&reserved=0> PREFIX def-ef:
>> <http://loc/
>> ation.data.gov.uk%2Fdef%2Fef%2FSamplingPoint%2F&data=05%7C02%7CHugo.M
>> ills%40agrimetrics.co.uk%7C063d6218fe6c42e9f0fc08dcd0fe04cc%7C6ca596a
>> 570584494965cb808e7ab8057%7C1%7C0%7C638615036644255110%7CUnknown%7CTW
>> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
>> 6Mn0%3D%7C0%7C%7C%7C&sdata=Ksgq7T2KBrNdoB43TRVg7flXGjWZN07UdjlroSytJ8
>> Y%3D&reserved=0>
>> PREFIX def-bwq:
>> <http://env/
>> ironment.data.gov.uk%2Fdef%2Fbathing-water-quality%2F&data=05%7C02%7C
>> Hugo.Mills%40agrimetrics.co.uk%7C063d6218fe6c42e9f0fc08dcd0fe04cc%7C6
>> ca596a570584494965cb808e7ab8057%7C1%7C0%7C638615036644259070%7CUnknow
>> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
>> CJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=qxrDe3tL3fTx0L6Gvw7MChg3JsrUCo5%2B1H
>> YxlsyRcgA%3D&reserved=0> PREFIX geo:
>> <http://www/
>> .w3.org%2F2003%2F01%2Fgeo%2Fwgs84_pos%23&data=05%7C02%7CHugo.Mills%40
>> agrimetrics.co.uk%7C063d6218fe6c42e9f0fc08dcd0fe04cc%7C6ca596a5705844
>> 94965cb808e7ab8057%7C1%7C0%7C638615036644262673%7CUnknown%7CTWFpbGZsb
>> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
>> %7C0%7C%7C%7C&sdata=o0nZ%2Ba3Uu5%2FnMcU4GJNanjue3EVjwvkV47p%2Fp4SxGT8
>> %3D&reserved=0> PREFIX dgu:
>> <http://ref/
>> erence.data.gov.uk%2Fdef%2Freference%2F&data=05%7C02%7CHugo.Mills%40a
>> grimetrics.co.uk%7C063d6218fe6c42e9f0fc08dcd0fe04cc%7C6ca596a57058449
>> 4965cb808e7ab8057%7C1%7C0%7C638615036644266165%7CUnknown%7CTWFpbGZsb3
>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
>> 7C0%7C%7C%7C&sdata=TX%2F4tKgEHtJt1yfSJofSrMLODYxErf5P6mampBaw6X8%3D&r
>> eserved=0> PREFIX dct:
>> <http://pur/
>> l.org%2Fdc%2Fterms%2F&data=05%7C02%7CHugo.Mills%40agrimetrics.co.uk%7
>> C063d6218fe6c42e9f0fc08dcd0fe04cc%7C6ca596a570584494965cb808e7ab8057%
>> 7C1%7C0%7C638615036644269432%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
>> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata
>> =ONPF0uWYN6hZdbs9M0x4D94APwqe99IIjM5PWEkZeao%3D&reserved=0>
>> PREFIX def-som:
>> <http://env/
>> ironment.data.gov.uk%2Fdef%2Fbwq-som%2F&data=05%7C02%7CHugo.Mills%40a
>> grimetrics.co.uk%7C063d6218fe6c42e9f0fc08dcd0fe04cc%7C6ca596a57058449
>> 4965cb808e7ab8057%7C1%7C0%7C638615036644272576%7CUnknown%7CTWFpbGZsb3
>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
>> 7C0%7C%7C%7C&sdata=t%2FadLJNa5DSYaq9vBvQXw5WXJiA0KrYS0dA1Sditz70%3D&r
>> eserved=0> PREFIX rdf:
>> <http://www/
>> .w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23&data=05%7C02%7CHugo.Mills%4
>> 0agrimetrics.co.uk%7C063d6218fe6c42e9f0fc08dcd0fe04cc%7C6ca596a570584
>> 494965cb808e7ab8057%7C1%7C0%7C638615036644276630%7CUnknown%7CTWFpbGZs
>> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>> D%7C0%7C%7C%7C&sdata=gWDWGCIpzMp8%2BxoFv4nl0X0yHJkQcx5%2FiZdlEsg%2F7s
>> E%3D&reserved=0> PREFIX dcterms:
>> <http://pur/
>> l.org%2Fdc%2Fterms%2F&data=05%7C02%7CHugo.Mills%40agrimetrics.co.uk%7
>> C063d6218fe6c42e9f0fc08dcd0fe04cc%7C6ca596a570584494965cb808e7ab8057%
>> 7C1%7C0%7C638615036644279993%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
>> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata
>> =y5sT3lHxZOeNrt%2BpfzamDj3PnO5m1Q%2FEZDwu5s7EU6Q%3D&reserved=0>
>> PREFIX def-stp:
>> <http://env/
>> ironment.data.gov.uk%2Fdef%2Fbwq-stp%2F&data=05%7C02%7CHugo.Mills%40a
>> grimetrics.co.uk%7C063d6218fe6c42e9f0fc08dcd0fe04cc%7C6ca596a57058449
>> 4965cb808e7ab8057%7C1%7C0%7C638615036644283137%7CUnknown%7CTWFpbGZsb3
>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
>> 7C0%7C%7C%7C&sdata=yFvyA5cb1fCtBjWdK%2FPpPndnRjYGC0ex3eHilmOfAHA%3D&r
>> eserved=0> PREFIX def-bw:
>> <http://env/
>> ironment.data.gov.uk%2Fdef%2Fbathing-water%2F&data=05%7C02%7CHugo.Mil
>> ls%40agrimetrics.co.uk%7C063d6218fe6c42e9f0fc08dcd0fe04cc%7C6ca596a57
>> 0584494965cb808e7ab8057%7C1%7C0%7C638615036644286348%7CUnknown%7CTWFp
>> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
>> n0%3D%7C0%7C%7C%7C&sdata=AwcboaYg8RipqnNfHEIjn44kQvK%2BDeGJMtEDB8tjkk
>> o%3D&reserved=0>
>>
>> SELECT DISTINCT ?item WHERE
>> {
>> {
>> BIND(xsd:dateTime(replace(str(now()), "\\..*$", "")) AS ?doi) { ?som
>> def-bw:bathingWater ?bwt .
>> ?som def-som:startOfSuspension ?start FILTER NOT EXISTS {?som
>> dct:isReplacedBy ?som2 } } OPTIONAL { ?som def-som:endOfSuspension
>> ?end } BIND(?som AS ?item) FILTER ( ( ( bound(?end) && ( ?start <=
>> ?doi ) ) && ( ?doi <= ?end )
>> ) || ( ( ! bound(?end) ) && ( ?start <= ?doi ) ) ) } UNION {
>> BIND(xsd:dateTime(replace(str(now()), "\\..*$", "")) AS ?doi) ?stp
>> def-stp:riskLevel def-stp:increased .
>> ?stp def-stp:bathingWater ?bwt .
>> ?stp def-stp:publishedAt ?padt .
>> ?stp def-stp:expiresAt ?end .
>> ?stp def-stp:predictedAt ?start
>> FILTER ( ( ?start <= ?doi ) && ( ?doi <= ?end ) ) FILTER NOT EXISTS {
>> ?stp2 def-stp:bathingWater ?bwt .
>> ?stp2 def-stp:publishedAt ?padt2 .
>> ?stp2 def-stp:expiresAt ?end2 .
>> ?stp2 def-stp:predictedAt ?start2
>> FILTER ( ( ( ?padt2 > ?padt ) && ( ?start2 <= ?doi ) ) && ( ?doi <=
>> ?end2 ) )
>> }
>> BIND(?stp AS ?item)
>> }
>> UNION
>> {
>> BIND(xsd:dateTime(replace(str(now()), "\\..*$", "")) AS ?doi) { ?pi
>> rdf:type def-som:PollutionIncident .
>> ?pi def-bw:bathingWater ?bwt .
>> ?pi def-som:startOfIncident ?start
>> FILTER NOT EXISTS {?pi dct:isReplacedBy ?other } } OPTIONAL { ?pi
>> def-som:endOfIncident ?end } FILTER ( ( ?start <= ?doi ) && ( ( !
>> bound(?end) ) || ( ?doi <= ?end
>> ) ) )
>> BIND(?pi AS ?item)
>> }
>> OPTIONAL {
>> ?item def-stp:riskLevel ?___1 .
>> ?___1 def-stp:riskNotation ?___0
>> }
>> OPTIONAL {
>> ?item def-stp:samplingPoint ?___3 .
>> ?___3 geo:long ?___2
>> }
>> OPTIONAL {
>> ?item def-ef:samplingPoint ?___5 .
>> ?___5 spatialrelations:northing ?___4 } OPTIONAL { ?item dgu:uriSet
>> ?___7 .
>> ?___7 rdf:type ?___6
>> }
>> OPTIONAL {
>> ?item def-bwq:sampleYear ?___9 .
>> ?___9 skos:prefLabel ?___8
>> }
>> OPTIONAL {
>> ?item def-stp:predictedAt ?___10
>> }
>> OPTIONAL {
>> ?item def-bw:bathingWater ?___12 .
>> ?___12 rdf:type ?___11
>> }
>> OPTIONAL {
>> ?item def-som:incidentType ?___14 .
>> ?___14 rdf:type ?___13
>> }
>> OPTIONAL {
>> ?item def-som:notation ?___15
>> }
>> OPTIONAL {
>> ?___2 spatialrelations:northing ?___16 } OPTIONAL { ?item
>> def-som:recordDateTime ?___17 } OPTIONAL { ?item
>> def-som:startOfIncident ?___18 } OPTIONAL { ?item dct:description
>> ?___19 } OPTIONAL {
>> ?___4 geo:lat ?___20
>> }
>> OPTIONAL {
>> ?item def-som:nirsRef ?___21
>> }
>> }
>> ORDER BY ?___0 DESC(?___2) DESC(?___4) ?___6 ?___8 ?___10
>> DESC(?___11)
>> DESC(?___13) ?___15 ?___16 ?___17 ?___18 DESC(?___19)
>> DESC(?___20) DESC(?___21) ?item
>> OFFSET 0
>> LIMIT 25
>>
>> I suspect that this query has been machine-generated by some code
>> within the app (as I think I've mentioned, we didn't write this;
>> we're just having to maintain it now). The original formatting is not
>> what a human would have written. Most of the queries that the app is
>> sending to Fuseki look similar. I haven't worked through what the
>> differences on the long-running ones are yet, but will be doing that
>> in detail today.
>>
>>> + details about the data (e.g. how many triples, any inference
>>> being
>>> applied, how is the data stored?
>>
>> Rough order of magnitude: 20MT. No inference, stored as TDB (see
>> below).
>>
>>> + Is Fuseki being run standalone or as a WAR file?
>>
>> Standalone.
>>
>>> + Fuseki configuration (config.ttl).
>>
>> @prefix : <#> .
>> @prefix fuseki: <http://jena.apache.org/fuseki#> .
>> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>> @prefix tdb: <http://jena.hpl.hp.com/2008/tdb#> .
>> @prefix ja: <http://jena.hpl.hp.com/2005/11/Assembler#> .
>>
>> [] rdf:type fuseki:Server ;
>> ja:context [ ja:cxtName "arq:queryTimeout" ; ja:cxtValue
>> "20000,40000" ] ; ja:context [ ja:cxtName "arq:logExec" ; ja:cxtValue
>> "all" ] ; ja:context [ ja:cxtName "arq:optReorderBGP" ; ja:cxtValue
>> "all" ] ;
>>
>> fuseki:services (
>> <#service_ds>
>> ) .
>>
>> # TDB
>> [] ja:loadClass "com.hp.hpl.jena.tdb.TDB" .
>> tdb:DatasetTDB rdfs:subClassOf ja:RDFDataset .
>> tdb:GraphTDB rdfs:subClassOf ja:Model .
>>
>> <#service_ds> rdf:type fuseki:Service ; rdfs:label "TDB Service (RW)"
>> ; fuseki:name "ds" ; fuseki:serviceQuery "query" ;
>> fuseki:serviceQuery "sparql" ; fuseki:serviceUpdate "update" ;
>> fuseki:serviceUpload "upload" ; fuseki:serviceReadWriteGraphStore
>> "data" ; # A separate read-only graph store endpoint:
>> fuseki:serviceReadGraphStore "get" ;
>> fuseki:dataset <#ds> ;
>> .
>>
>> <#ds> rdf:type tdb:DatasetTDB ;
>> tdb:location "/fuseki/databases/DS-DB" ; tdb:unionDefaultGraph true ;
>> .
>>
>>> + JVM version, and heap setting. Did you adjust he settings after
>>> https://lists.apache.org/thread/5d98v6j49zdy042fxwwtnkhcfvl69206 ?
>>
>> OpenJDK 19, and, after that thread, we reduced the JVM memory
>> settings to: -Xmx18g -Xms18g. (Yes, I realise that this is still
>> huge, but it's now at least a lot smaller than the container).
>>
>>> Jena 3.4.0 is very old. There are security fixes for Jena and for
>>> dependencies that have happen over the last 7 years.
>>
>> As I think I mentioned elsewhere (and in the thread linked above),
>> last time we tried upgrading Fuseki in this deployment, we had
>> problems with memory usage. But I guess we're going to have to try
>> again.
>>
>>> Andy
>>
>>> Cheers,
>>>
>>> On Fri, 2024-09-06 at 15:20 +0000, Hugo Mills wrote:
>>>>
>>>>
>>>>
>>>> As described in an earlier email to this list, we’ve got a problem
>>>> with our installation of Fuseki 3.4.0(*) where it goes into a state
>>>> of very high CPU usage, and load average climbs to high levels,
>>>> leading to the database becoming unresponsive. We’ve managed to
>>>> extract some stats on queries when this happens, and while we
>>>> haven’t been able to draw any conclusions on why it happens, we
>>>> have spotted one odd thing.
>>>>
>>>> We’ve got a server-wide timeout setting of “20000,40000”. When the
>>>> server is behaving, almost all queries are answered within 100ms.
>>>> When it’s not, we see queries running for much, much longer – in
>>>> some cases, up to almost 6 minutes. This would seem to be something
>>>> of a mismatch with the timeout settings. I would expect to see a
>>>> bunch of queries being killed at shortly after 20s, and a bunch
>>>> being killed at shortly after 40s, and nothing beyond that point.
>>>> Why is Fuseki ignoring the timeout settings we’ve given it? Is
>>>> there a parameter that can be passed to Fuseki (an HTTP header?)
>>>> which overrides the default timeouts? Have we simply misunderstood
>>>> what the timeout setting in the server config file does?
>>>>
>>>> Thanks,
>>>> Hugo.
>>>>
>>>> (*) We’re running 3.4.0 because when we tried a later version, the
>>>> application failed even more often than it does right now. I don’t
>>>> know if the failure mode was the same as this one – that predates
>>>> this current investigation by a year or more, and I wasn’t involved
>>>> in that.
>>>> Hugo Mills
>>>>
>>>> Development Team Leader
>>>>
>>>> agrimetrics.co.uk
>>>>
>>>> Reading Enterprise Centre, Whiteknights Road, Reading, UK, RG6 6BU
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>
