Hi Hugh,
Sorry for wasting your time. I finally got the cause down.
When I saw this for the first time in the gdb
Program terminated with signal SIGKILL, Killed.
The program no longer exists.
And this in dmesg
Out of memory: Kill process 14738 (virtuoso-t) score 763 or sacrifice child
Killed process 14738, UID 21059, (virtuoso-t) total-vm:16179784kB,
anon-rss:12910420kB, file-rss:152kB
The total-vm size in that dmesg line is surprising its is nearly 16gb of
memory use.
Yet the NumberOfBuffers is 904897 (about 8 gb assuming 9KB pages) and
MaxDirtyBuffers 500000. The odd size of the NumberOfBuffers is due to
auto sizing this setting in the conf from the managing process as
virtuoso is basically running in a embedded/lite mode.
The server is in O_DIRECT mode (set to 1)
What can I set so that this does not happen? i.e. why is the memory
consumption so large during this SPARQL update? Is it because my max
result size?
Regards,
Jerven
On 13/02/14 20:57, Jerven Bolleman wrote:
Hi Hugh,
Yes, that should be the file (all those are the same)
I switched back to the stable branch because the develop/7 branch would not
build cleanly when I tried.
This happened before and you guys normally fix it and I was not in a hurry.
I finally have the debug build working and ulimit set etc… so I think I will
send the backtrace tomorrow.
Regards,
Jerven
On 13 Feb 2014, at 17:52, Hugh Williams <hwilli...@openlinksw.com> wrote:
Hi Jerven,
From our point of view there is no real value in building from the stable/7
branch from July last year, as it is about to be superseded in the new VOS 7
release by develop/7 when finalised, which is what we would be more interested
in knowing of any problem being encountered using ?
In your email below you mention loading the go.rdf.gz uniprot dataset, do you
have URL to what you loaded or is it one of:
<resources>
<url type="ftp" location="ch" preference="100">
ftp://ftp.expasy.org/databases/uniprot/current_release/rdf/go.rdf.gz
</url>
<url type="ftp" location="uk" preference="100">
ftp://ftp.ebi.ac.uk/pub/databases/uniprot/current_release/rdf/go.rdf.gz
</url>
<url type="ftp" location="us" preference="100">
ftp://ftp.uniprot.org/pub/databases/uniprot/current_release/rdf/go.rdf.gz
</url>
</resources>
and I can load here to try recreate your problem with develop/7 ?
Best Regards
Hugh Williams
Professional Services
OpenLink Software, Inc. // http://www.openlinksw.com/
Weblog -- http://www.openlinksw.com/blogs/
LinkedIn -- http://www.linkedin.com/company/openlink-software/
Twitter -- http://twitter.com/OpenLink
Google+ -- http://plus.google.com/100570109519069333827/
Facebook -- http://www.facebook.com/OpenLinkSoftware
Universal Data Access, Integration, and Management Technology Providers
On 13 Feb 2014, at 10:14, Jerven Bolleman <jerven.bolle...@isb-sib.ch> wrote:
That was premature, I just reran the experiment and now it crashed again :(
Will try to see where that core dump went.
Regards,
Jerven
On 13/02/14 09:25, Jerven Bolleman wrote:
Hi All,
I have managed to build a debug build.
The funny thing is it now succeeds!
I do get this message once the next time I call a checkpoint.
18:02:22 suspect to miss a flush of L=100 in cpt, line 1008
18:02:23 Buffer 0x7fc9f79516f8 occupied in cpt
Regards,
Jerven
On 11/02/14 16:06, Jerven Bolleman wrote:
Hi Hugh,
I don't understand how to build the debug release.
I can't find the lines to patch e.g.
cd /scratch/virtuoso-opensource
git pull;git status;
grep CONFIGURE_ARGS Makefile
remote: Counting objects: 298, done.
remote: Compressing objects: 100% (298/298), done.
remote: Total 298 (delta 174), reused 0 (delta 0)
Receiving objects: 100% (298/298), 1.44 MiB | 974 KiB/s, done.
Resolving deltas: 100% (174/174), done.
From git://github.com/openlink/virtuoso-opensource
74ed20c..0b71fb6 develop/7 -> origin/develop/7
Already up-to-date.
# On branch stable/7
nothing to commit (working directory clean)
As you can notice I am now trying out the stable branch.
Because when I tried building the develop/7 branch yesterday I had a
failure.
I do have a better idea of what is going on to trigger the bug.
First of all I have rewritten the update statement to look like this.
PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
INSERT { GRAPH <http://beta.sparql.uniprot.org/taxonomy> {
?sub rdfs:subClassOf ?super}}
WHERE {
SELECT DISTINCT ?super ?sub
WHERE {GRAPH <http://beta.sparql.uniprot.org/taxonomy> {
?sub rdfs:subClassOf [] .
?sub rdfs:subClassOf/rdfs:subClassOf+ ?super .
[] rdfs:subClassOf ?super . }
}
}
Which runs in about 25 minutes for the taxonomy data I have been using.
Once the TransactionAfterImageLimit is raised (in my case to about 1GB
or 1000000000 bytes)
Then I try loading the go.rdf.gz data into a named which works fine and
run the nearly identical query.
PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
INSERT { GRAPH <http://beta.sparql.uniprot.org/go> {
?sub rdfs:subClassOf ?super}}
WHERE {
SELECT DISTINCT ?super ?sub
WHERE {GRAPH <http://beta.sparql.uniprot.org/go> {
?sub rdfs:subClassOf [] .
?sub rdfs:subClassOf/rdfs:subClassOf+ ?super .
[] rdfs:subClassOf ?super . }
}
}
At this time the database starts to die again :(
?sub rdfs:subClassOf [] .
and
[] rdfs:subClassOf ?super
are there to ground ?sub and ?super or I get an error from the query
engine but without those the query is valid SPARQL as well.
I think this is fixed in the develop branch.
As you might have noticed from yesterday's message about the clob/blob
api for Virtuoso JDBC I was investigating better ways of loading the
data again.
Currently I build a Turtle string that is passed to the virtuoso side
where it is loaded via TTLP or TTLP_MT. However, it is sad that I go
from structured data to a string to be parsed again on the other side.
I was hoping that there would be a better way to generate a data
structure that does not require as much parsing by virtuoso.
On large datasets this might not be a noticable overhead but on the
small datasets that I am now testing I notice that we are running out of
CPU power before IO/MEM.
I was wondering if an API where we can pass 4 (or 5) array's to a
prepared statement instead of a string to parse can really improve the
loading speed.
e.g.
one array of subjects
one array of predicates
one array of objects
optional one of datatypes
one array of graphs
If this does not match your needs then another feature requests is
better blob/clob support in virtuoso.
Currently I can figure out how to create them but not how to actually
put data into them without being in a virtuoso package.
Regards,
Jerven
On 28/01/14 06:03, Hugh Williams wrote:
Hi Jerven,
I have run the query many times, but as said I keep getting the "SR325:
Transaction aborted because it's log after image size went above the
limit" first time the query is run and have to increase
the "TransactionAfterImageLimit" param in the INI file. Thus have you
encountered this error yourself or do you even have
the "TransactionAfterImageLimit" param set for your instance as I am
wondering if this might be the cause of the crash you are seeing on your
instance and perhaps the param needs to be increased for your instance ?
Best Regards
Hugh Williams
Professional Services
OpenLink Software, Inc. // http://www.openlinksw.com/
Weblog -- http://www.openlinksw.com/blogs/
LinkedIn -- http://www.linkedin.com/company/openlink-software/
Twitter -- http://twitter.com/OpenLink
Google+ -- http://plus.google.com/100570109519069333827/
Facebook -- http://www.facebook.com/OpenLinkSoftware
Universal Data Access, Integration, and Management Technology Providers
On 27 Jan 2014, at 13:52, Jerven Bolleman <jerven.bolle...@isb-sib.ch
<mailto:jerven.bolle...@isb-sib.ch>> wrote:
Hi Hugh,
Sorry I won’t have time to get a memory dump for at least two weeks.
However, I must have explained something badly you need to run the
insert query 4 or 5 times in a row to get the crash.
Regards,
Jerven
On 26 Jan 2014, at 15:51, Hugh Williams <hwilli...@openlinksw.com
<mailto:hwilli...@openlinksw.com>> wrote:
Hi Jerven,
I have tried recreating this against the VOS develop/7 branch on Mac
OS X but have been unable to do so ...
Hughs-MacBook-Pro-478:database hwilliams$ /Applications/Virtuoso\
7.1.app/Contents/virtuoso/bin/isql 1111
Connected to OpenLink Virtuoso
Driver: 07.10.3207 OpenLink Virtuoso ODBC Driver
OpenLink Interactive SQL (Virtuoso), version 0.9849b.
Type HELP; for help and EXIT; to exit.
SQL> status('');
REPORT
VARCHAR
_______________________________________________________________________________
OpenLink Virtuoso Server
Version 07.00.3207-pthreads for Darwin as of Dec 10 2013
Started on: 2014-01-26 14:16 GMT+0
Database Status:
File size 614465536, 75008 pages, 51817 free.
170000 buffers, 21735 used, 0 dirty 0 wired down, repl age 0 0 w. io
0 w/crsr.
Disk Usage: 524 reads avg 1 msec, 0% r 0% w last 0 s, 21387 writes,
13 read ahead, batch = 14. Autocompact 40700 in 18150 out, 55%
saved col ac: 4997 in 47% saved.
Gate: 44 2nd in reads, 0 gate write waits, 0 in while read 0 busy
scrap.
Log = /usr/local/vos7/database/virtuoso.trx, 185 bytes
23061 pages have been changed since last backup (in checkpoint state)
Current backup timestamp: 0x0000-0x00-0x00
Last backup date: unknown
Clients: 1 connects, max 1 concurrent
RPC: 4 calls, 1 pending, 1 max until now, 0 queued, 0 burst reads
(0%), 0 second 0M large, 83M max
Checkpoint Remap 95 pages, 0 mapped back. 0 s atomic time.
DB master 75008 total 51817 free 95 remap 0 mapped back
temp 1024 total 1019 free
Lock Status: 0 deadlocks of which 0 2r1w, 0 waits,
Currently 1 threads running 0 threads waiting 0 threads in vdb.
Pending:
23 Rows. -- 8 msec.
SQL> DB.DBA.RDF_LOAD_RDFXML_MT (file_to_string_output
('./taxonomy.rdf'), '', 'http://beta.sparql.uniprot.org/taxonomy/');
Done. -- 118988 msec.
SQL> SPARQL PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
INSERT { GRAPH <http://beta.sparql.uniprot.org/taxonomy/> { ?sub
rdfs:subClassOf ?super}} WHERE { GRAPH
<http://beta.sparql.uniprot.org/taxonomy/> { ?sub
rdfs:subClassOf/rdfs:subClassOf ?super . MINUS { ?sub rdfs:subClassOf
?super .}}};
*** Error 40005: VD [Virtuoso Server]SR325: Transaction aborted
because it's log after image size went above the limit
at line 4 of Top-Level:
SPARQL PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#> INSERT {
GRAPH <http://beta.sparql.uniprot.org/taxonomy/> { ?sub
rdfs:subClassOf ?super}} WHERE { GRAPH
<http://beta.sparql.uniprot.org/taxonomy/> { ?sub
rdfs:subClassOf/rdfs:subClassOf ?super . MINUS { ?sub rdfs:subClassOf
?super .}}}
SQL>
I got around the SR325 erro by doubling the
"TransactionAfterImageLimit" param in the INI file from the default
of 50000000 to 100000000 and restarted Virtuoso as indicated in the
documentation at:
http://docs.openlinksw.com/virtuoso/databaseadmsrv.html#dbadm
Then the insertion was successful:
Hughs-MacBook-Pro-478:database hwilliams$ /Applications/Virtuoso\
7.1.app/Contents/virtuoso/bin/isql 1111
Connected to OpenLink Virtuoso
Driver: 07.10.3207 OpenLink Virtuoso ODBC Driver
OpenLink Interactive SQL (Virtuoso), version 0.9849b.
Type HELP; for help and EXIT; to exit.
SQL> SPARQL PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
INSERT { GRAPH <http://beta.sparql.uniprot.org/taxonomy/> { ?sub
rdfs:subClassOf ?super}} WHERE { GRAPH
<http://beta.sparql.uniprot.org/taxonomy/> { ?sub
rdfs:subClassOf/rdfs:subClassOf ?super . MINUS { ?sub rdfs:subClassOf
?super .}}};
Done. -- 41081 msec.
SQL> sparql select count(*) from
<http://beta.sparql.uniprot.org/taxonomy/> where {?s ?p ?o};
callret-0
INTEGER
_______________________________________________________________________________
9549986
1 Rows. -- 150 msec.
SQL>
In your case Is a core file being created when the server crashes (
note core size for user account should be set to be unlimited with
command “ulimit -c unlimited” first), as if so you can create a debug
unstripped Virtuoso binary, recreate the core with it and use gdb to
debug it as follows:
1. Edit ~//Makefile
2. To CONFIGURE_ARGS add --with-debug
3. To CONFIGURE_ENV prepend CC='cc -g’
4. Then do "make clean all deinstall reinstall” to build a new debug
unstripped binary (virtuoso-t)
5. Start database with this new binary and force the crash condition
again to generate a new core file
6. Use gdb to load core file
gdb virtuoso-t core
7. At the prompt, type "bt" or “backtrace” to backtrace through
stack and provide the output when top of stack is reached.
Best Regards
Hugh Williams
Professional Services
OpenLink Software, Inc. //
http://www.openlinksw.com/
Weblog -- http://www.openlinksw.com/blogs/
LinkedIn -- http://www.linkedin.com/company/openlink-software/
Twitter -- http://twitter.com/OpenLink
Google+ -- http://plus.google.com/100570109519069333827/
Facebook -- http://www.facebook.com/OpenLinkSoftware
Universal Data Access, Integration, and Management Technology
Providers
On 22 Jan 2014, at 11:08, Jerven Bolleman
<jerven.bolle...@isb-sib.ch> wrote:
Dear Virtuoso devs,
On commit 2701d3f242a630562302471d168d20fec5ed2805 of the develop/7
branch.
I load the file
ftp://ftp.uniprot.org/pub/databases/uniprot/current_release/rdf/taxonomy.rdf.gz
into the graph named
http://beta.sparql.uniprot.org/taxonomy/.
Then checkpoint. Then I the run the SPARUL query
PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
INSERT { GRAPH <http://beta.sparql.uniprot.org/taxonomy/> {
?sub rdfs:subClassOf ?super}}
WHERE { GRAPH <http://beta.sparql.uniprot.org/taxonomy/> {
?sub
rdfs:subClassOf/rdfs:subClassOf ?super .
MINUS { ?sub rdfs:subClassOf ?super .}}}
I get a message
17:27:41 * Monitor: Low query memory limit, try to increase
MaxQueryMem
Then I again run the same query
PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
INSERT { GRAPH <http://beta.sparql.uniprot.org/taxonomy/> {
?sub rdfs:subClassOf ?super}}
WHERE { GRAPH <http://beta.sparql.uniprot.org/taxonomy/> {
?sub
rdfs:subClassOf/rdfs:subClassOf ?super .
MINUS { ?sub rdfs:subClassOf ?super .}}}
And virtuoso crashes without leaving a trace in the logs.
The query log shows the first execution but not the second.
And that looks like this
Precode:
0: { FOR UPDATE
time -nan% fanout 1 input 1 rows
time -nan% fanout 1 input 1 rows
Precode:
0: vector := Call vector ( 1 , 0 , 3 , ##subClassOf , 1 , 1 )
5: vector := Call vector (vector)
10: vector := Call vector ()
15: __bft := Call __bft (<c
http://beta.sparql.uniprot.org/taxonomy/>, 1 )
20: BReturn 0
{ fork
time -nan% fanout 1.09875e+06 input 1 rows
RDF_QUAD_POGS 2.4e+03 rows(s_6_4_t1.O, s_6_4_t1.S)
inlined P = ##subClassOf G = #/
time -nan% fanout 0.999965 input 1.09875e+06 rows
RDF_QUAD 1 rows(s_6_7_t2.O)
inlined P = ##subClassOf , S = k_s_6_4_t1.O G = #/
time -nan% fanout 0 input 1.09871e+06 rows
END Node
After test:
0: if ({
time -nan% fanout 1 input 1.09871e+06 rows
time -nan% fanout 0 input 1.09871e+06 rows
RDF_QUAD_POGS unq 0.0011 rows ()
P = ##subClassOf , O = k_s_6_7_t2.O , S = k_s_6_4_t1.S , G = #/
time -nan% fanout 0 input 0 rows
Subquery Select( <none> )
}
) then 5 else 4 unkn 5
4: BReturn 1
5: BReturn 0
After code:
0: __ro2lo := Call __ro2lo (s_6_7_t2.O)
5: vector := Call vector (s_6_4_t1.S, __ro2lo)
10: if ($63 "user_aggr_notfirst" = 1 ) then 25 else 14 unkn 14
14: $63 "user_aggr_notfirst" := := artm 1
18: user_aggr_ret := Call DB.DBA.SPARQL_CONSTRUCT_INIT ($64
"user_aggr_env")
25: user_aggr_ret := Call DB.DBA.SPARQL_CONSTRUCT_ACC ($64
"user_aggr_env", vector, vector, vector, 0 )
32: BReturn 0
}
time -nan% fanout 1 input 1 rows
skip node 1 <none> set_ctr
After code:
0: DB.DBA.SPARQL_CONSTRUCT_FIN := Call
DB.DBA.SPARQL_CONSTRUCT_FIN ($64 "user_aggr_env")
7: callret-0 := Call DB.DBA.SPARQL_INSERT_DICT_CONTENT (__bft,
DB.DBA.SPARQL_CONSTRUCT_FIN, 0 , <DB_NULL>, 0 )
14: BReturn 0
time -nan% fanout 0 input 1 rows
skip node 1 <none> set_ctr
After code:
0: DB.DBA.SPARQL_CONSTRUCT_FIN := Call
DB.DBA.SPARQL_CONSTRUCT_FIN ($64 "user_aggr_env")
7: callret-0 := Call DB.DBA.SPARQL_INSERT_DICT_CONTENT (__bft,
DB.DBA.SPARQL_CONSTRUCT_FIN, 0 , <DB_NULL>, 0 )
14: BReturn 0
time -nan% fanout 0 input 1 rows
Subquery Select(callret-0)
}
8: $184 "vector" := Call vector ($185 "scalar")
13: $183 "DB.DBA.SPARUL_RUN" := Call DB.DBA.SPARUL_RUN ($184
"vector")
20: <none> := Call set_row_count ($183 "DB.DBA.SPARUL_RUN")
25: BReturn 0
END Node
}
^@^B<80>^@<BD>^@^P<C3><D7><C1><BC>+<BD>^@^@8Z<D3>^K8^X^PqP^@ESC
<<BC>^@<BC>^@<B5>
127.0.0.1<B5>^Cdba<CC>^S<BD>^@#k<A2><BD>^@^@G <B5>^Nlog_enable
(3)^A<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@
<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<B6>^@^@^@W{
Precode:
0: <none> := Call log_enable ( 3 )
5: BReturn 0
END Node
}
^@^A@^@<BC>^@<C1><BC>+<BD>^@^@8[<D3>^K8^X^PqP^@^\ <<BC>^@<BC>^@<B5>
127.0.0.1<B5>^Cdba<CC>^S<BD>^@#k<A3><BD>^@^@G
<B5>^Xcheckpoint_interval
(60)^A<BC>^@<BC>^A<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@
<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<B6>^@^@^@a{
Precode:
0: <none> := Call checkpoint_interval ( 60 )
5: BReturn 0
END Node
}
^@^A@^@<BC>^@<C1><BC>+<BD>^@^@8\<D3>^K8^X^PqP^@^^ <<BC>^@<BC>^@<B5>
127.0.0.1<B5>^Cdba<CC>^S<BD>^@#k<B6><BD>^@^@G
<B5>^Wcheckpoint_interval
(0)^A<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@
<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<B6>^@^@^@`{
Precode:
0: <none> := Call checkpoint_interval ( 0 )
5: BReturn 0
END Node
}
^@^A@^@<BC>^@<C1><BC>+<BD>^@^@8]<D3>^K8^X^PqP^@^_ <<BC>^@<BC>^@<B5>
127.0.0.1<B5>^Cdba<CC>^S<BD>^@#k<B6><BD>^@^@G <B5>^Nlog_enable
(0)^A<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>
^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<B6>^@^@^@W{
Precode:
0: <none> := Call log_enable ( 0 )
5: BReturn 0
END Node
}
I would expect the next query to show up here but it did not. The
change to the checkpoint interval and logging status show that the
two statements before the SPARUL succeeded.
The exception caught from the java side is
Exception:virtuoso.jdbc4.VirtuosoException: Virtuoso Communications
Link Failure (timeout) : Connection to the server lost
at
virtuoso.sesame2.driver.VirtuosoRepositoryConnection.executeSPARUL(Unknown
Source)
at
virtuoso.sesame2.driver.VirtuosoRepositoryConnection$4.execute(Unknown
Source)
Is there a way I can change the error log level to be more
verbose/helpfull?
Regards,
Jerven
--
-------------------------------------------------------------------
Jerven Bolleman jerven.bolle...@isb-sib.ch
SIB Swiss Institute of Bioinformatics Tel: +41 (0)22 379 58 85
CMU, rue Michel Servet 1 Fax: +41 (0)22 379 58 58
1211 Geneve 4,
Switzerland www.isb-sib.ch - www.uniprot.org
Follow us at https://twitter.com/#!/uniprot
-------------------------------------------------------------------
<virtuoso-config-expasy4j-sparql702803043962519654.ini><virtuoso.log>------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk_______________________________________________
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users
-------------------------------------------------------------------
Jerven Bolleman jerven.bolle...@isb-sib.ch
<mailto:jerven.bolle...@isb-sib.ch>
SIB Swiss Institute of Bioinformatics Tel: +41 (0)22 379 58 85
CMU, rue Michel Servet 1 Fax: +41 (0)22 379 58 58
1211 Geneve 4,
Switzerland www.isb-sib.ch <http://www.isb-sib.ch> - www.uniprot.org
<http://www.uniprot.org>
Follow us at https://twitter.com/#!/uniprot
-------------------------------------------------------------------
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users
--
-------------------------------------------------------------------
Jerven Bolleman jerven.bolle...@isb-sib.ch
SIB Swiss Institute of Bioinformatics Tel: +41 (0)22 379 58 85
CMU, rue Michel Servet 1 Fax: +41 (0)22 379 58 58
1211 Geneve 4,
Switzerland www.isb-sib.ch - www.uniprot.org
Follow us at https://twitter.com/#!/uniprot
-------------------------------------------------------------------
------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users
-------------------------------------------------------------------
Jerven Bolleman jerven.bolle...@isb-sib.ch
SIB Swiss Institute of Bioinformatics Tel: +41 (0)22 379 58 85
CMU, rue Michel Servet 1 Fax: +41 (0)22 379 58 58
1211 Geneve 4,
Switzerland www.isb-sib.ch - www.uniprot.org
Follow us at https://twitter.com/#!/uniprot
-------------------------------------------------------------------
--
-------------------------------------------------------------------
Jerven Bolleman jerven.bolle...@isb-sib.ch
SIB Swiss Institute of Bioinformatics Tel: +41 (0)22 379 58 85
CMU, rue Michel Servet 1 Fax: +41 (0)22 379 58 58
1211 Geneve 4,
Switzerland www.isb-sib.ch - www.uniprot.org
Follow us at https://twitter.com/#!/uniprot
-------------------------------------------------------------------
;
; virtuoso.ini
;
; Database setup
;
[Database]
DatabaseFile =
/home/jbollema/git/expasy4j-sparql/./data/virtuoso/virtuoso.db
ErrorLogFile =
/home/jbollema/git/expasy4j-sparql/./data/virtuoso/virtuoso.log
LockFile =
/home/jbollema/git/expasy4j-sparql/./data/virtuoso/virtuoso.lck
TransactionFile =
/home/jbollema/git/expasy4j-sparql/./data/virtuoso/virtuoso.trx
xa_persistent_file =
/home/jbollema/git/expasy4j-sparql/./data/virtuoso/virtuoso.pxa
ErrorLogLevel = 7
FileExtend = 20000
MaxCheckpointRemap = 20000
Striping = 0
TempStorage = TempDatabase
[TempDatabase]
DatabaseFile =
/home/jbollema/git/expasy4j-sparql/./data/virtuoso/virtuoso-temp.db
TransactionFile =
/home/jbollema/git/expasy4j-sparql/./data/virtuoso/virtuoso-temp.trx
MaxCheckpointRemap = 2000
Striping = 0
;
; Server parameters
;
[Parameters]
ServerPort = 1112
LiteMode = 1
DisableUnixSocket = 0
DisableTcpSocket = 0
ServerThreads = 4
CheckpointInterval = 60
O_DIRECT = 1
UseAIO = 1
CaseMode = 2
MaxStaticCursorRows = 5000
CheckpointAuditTrail = 0
AllowOSCalls = 0
SchedulerInterval = 10
DirsAllowed =
ThreadCleanupInterval = 0
ThreadThreshold = 10
ResourcesCleanupInterval = 0
FreeTextBatchSize = 100000
SingleCPU = 0
VADInstallDir = /dev/null
PrefixResultNames = 0
RdfFreeTextRulesSize = 100
IndexTreeMaps = 256
MaxMemPoolSize = 0
TransactionAfterImageLimit = 1000000000
ColumnStore = 1
QueryLog =
/tmp/virtuoso-query.log
NumberOfBuffers = 904897
MaxDirtyBuffers = 500000
ThreadsPerQuery = 4
MaxQueryMem = 200M
VectorSize = 10000
MaxVectorSize = 1000000
AdjustVectorSize = 1
[AutoRepair]
BadParentLinks = 0
[Client]
SQL_PREFETCH_ROWS = 100
SQL_PREFETCH_BYTES = 16000
SQL_QUERY_TIMEOUT = 0
SQL_TXN_TIMEOUT = 0
[VDB]
ArrayOptimization = 0
NumArrayParameters = 10
VDBDisconnectTimeout = 1000
KeepConnectionOnFixedThread = 0
;
; Striping setup
;
; These parameters have only effect when Striping is set to 1 in the
; [Database] section, in which case the DatabaseFile parameter is ignored.
;
; With striping, the database is spawned across multiple segments
; where each segment can have multiple stripes.
;
; Format of the lines below:
; Segment<number> = <size>, <stripe file name> [, <stripe file name> .. ]
;
; <number> must be ordered from 1 up.
;
; The <size> is the total size of the segment which is equally divided
; across all stripes forming the segment. Its specification can be in
; gigabytes (g), megabytes (m), kilobytes (k) or in database blocks
; (b, the default)
;
; Note that the segment size must be a multiple of the database page size
; which is currently 8k. Also, the segment size must be divisible by the
; number of stripe files forming the segment.
;
; The example below creates a 200 meg database striped on two segments
; with two stripes of 50 meg and one of 100 meg.
;
; You can always add more segments to the configuration, but once
; added, do not change the setup.
;
;[Striping]
;Segment1 = 100M,
/home/jbollema/git/expasy4j-sparql/./data/virtuoso/db-seg1-1.db
;Segment2 = 100M,
/home/jbollema/git/expasy4j-sparql/./data/virtuoso/db-seg2-1.db
;...
;[TempStriping]
;Segment1 = 100M,
/home/jbollema/git/expasy4j-sparql/./data/virtuoso/temp-db-seg1-1.db
;Segment2 = 100M,
/home/jbollema/git/expasy4j-sparql/./data/virtuoso/temp-db-seg2-1.db
;...
[SPARQL]
;ExternalQuerySource = 1
;ExternalXsltSource = 1
DefaultGraph =
http://beta.sparql.uniprot.org/
ResultSetMaxRows = 80000000
MaxQueryCostEstimationTime = 360000 ; in seconds
MaxQueryExecutionTime = 360000 ; in seconds
DefaultQuery =
select distinct ?Concept where {[] a ?Concept} LIMIT 100
DeferInferenceRulesInit = 0 ; controls inference rules loading
------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users
