On 22/12/14 22:58, Petr Baudis wrote:
Hi!
On Mon, Dec 22, 2014 at 08:46:39PM +0000, Andy Seaborne wrote:
If there a a few connections (<=2) and large numbers of small
queries issued over each connection. Assuming there are no sorts and
no timeouts set, then the execution of the query should be all on
the thread that it came in on. And you 8 (shame it's not 8*8!)
cores. Do you have couple of example queries you can share?
Sure! It is typically something like
PREFIX dc: <http://purl.org/dc/elements/1.1/> PREFIX : <http://dbpedia.org/resource/> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#> PREFIX
dbpedia2: <http://dbpedia.org/property/> PREFIX foaf: <http://xmlns.com/foaf/0.1/> PREFIX dbo: <http://dbpedia.org/ontology/> PREFIX owl:
<http://www.w3.org/2002/07/owl#> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#> PREFIX dbpedia: <http://dbpedia.org/> PREFIX rdf:
<http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX skos: <http://www.w3.org/2004/02/skos/core#> SELECT ?t WHERE { { ?res rdfs:label "California"@en }
UNION { ?redir dbo:wikiPageRedirects ?res . ?redir rdfs:label "California"@en } ?res rdf:type ?t FILTER ( ! regex(str(?res),
"^http://dbpedia.org/resource/[^_]*:";, "i") ) }
or variations for different labels.
Does the CPU load increase to start with, then drops off?
Fuseki/TDB is typically CPU-busy when the OS warms up and the
working set index files is memory.
I see no obvious CPU load variations. A lot of the queries are
repeated (so quickly warmed cache) and the server runs the user software
itself too.
Maybe the first thing to try is to point jvisualvm (in the JDK) or
some other monitoring tool at the Fuseki process and see if there is
any evidence. The thread dump would be useful. (jconsole even has a
"Detect Deadlock" which I have never used but the button label is
suggestive)
Hmm, seems like that requires a GUI. I can give that a whirl at the
end of the week as I have only remote access to the machine until then.
You can do it from the command line with the original tool that was sept
up into jvisualvm:
jstack ProcessId > stack_dump
(IIRC it's officially unsupported these days, but my Java 7 and 8
installations have it)
Andy
