Re: [Virtuoso-users] list graph query performance in V7.2.2 ?
Hi Thomas,
You can use the Virtuoso PL Debugger to see what procedures/statements are
running on the server continuously as follows:
$ isql dba -D
OpenLink Interactive PL Debugger (Virtuoso).
Type EXIT to exit, HELP for help
Debug session estabilished to
DEBUG> info threads
@:4 in DB.DBA.test_proc1 () at 11
DEBUG>
See the following documentation of additional details on usage:
http://docs.openlinksw.com/virtuoso/pldebugger.html#pldebugger
With regards to the "SR175: Uniqueness violation : Violating unique index
VSPX_SESSION on table DB.DBA.VSPX_SESSION. Transaction killed.” messages in
your log, the DB.DBA.VSPX_SESSION table does not hold for a long period of
time, thus you can try dropping the table and restarting Virtuoso which would
automatically recreate it. As ever please ensure you have a Full backup in
place first …
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 5 Apr 2016, at 15:24, Thomas Michaux wrote:
>
> ok, glad to know you're aware of these kind of issues...
>
> don't know if it can help you but before your suggestion (when i had
> AdjustVectorSize = 1) i was experimenting "waits" issues (message " *
> Monitor: Locks are held for a long time" in the logs), i tried to
> investigate with stats query (select top 10 * from sys_l_stat order by
> waits desc;) and was only able to notice a lot of wait time was on
> VSPX_SESSION index at the top of stats locks results.
>
> ...and after your suggestion (AdjustVectorSize = 0), i dont' know if
> it's linked, but i noticed these messages in the logs :
>
> 12:56:52 OpenLink Virtuoso Universal Server
> 12:56:52 Version 07.20.3215-pthreads for Linux as of Mar 29 2016
> 12:56:52 uses parts of OpenSSL, PCRE, Html Tidy
> 12:57:02 Database version 3126
> 12:57:02 SQL Optimizer enabled (max 1000 layouts)
> 12:57:04 Compiler unit is timed at 0.000205 msec
> 12:57:21 Roll forward started
> 12:57:21 SQL Error: 23000 : SR175: Uniqueness violation : Violating
> unique index VSPX_SESSION on table DB.DBA.VSPX_SESSION. Transaction killed.
> 12:57:21 In roll forward batch commit failed code 5
> 12:57:21 Rfwd error: 23000: SR175: Uniqueness violation : Violating
> unique index VSPX_SESSION on table DB.DBA.VSPX_SESSION. Transaction killed.
> 12:57:21 SQL Error: 23000 : SR175: Uniqueness violation : Violating
> unique index VSPX_SESSION on table DB.DBA.VSPX_SESSION. Transaction killed.
> 12:57:21 101 transactions, 10072 bytes replayed (100 %)
> 12:57:21 Roll forward complete
> 12:57:22 Checkpoint started
> 12:57:36 Checkpoint finished, new log is
> /usr/local/virtuoso-opensource/var/lib/virtuoso/db/virtuoso20160405125721.trx
> 12:57:38 HTTP/WebDAV server online at 8890
> 12:57:38 Server online at (pid 20868)
> 13:57:40 Checkpoint started
> 13:57:40 Checkpoint finished, new log is
> /usr/local/virtuoso-opensource/var/lib/virtuoso/db/virtuoso20160405135739.trx
> 14:57:42 Checkpoint started
> 14:57:42 Checkpoint finished, new log is
> /usr/local/virtuoso-opensource/var/lib/virtuoso/db/virtuoso20160405145741.trx
> 15:57:44 Checkpoint started
> 15:57:45 Checkpoint finished, new log is
> /usr/local/virtuoso-opensource/var/lib/virtuoso/db/virtuoso20160405155743.trx
>
> Thomas
>
>
> Le 05/04/2016 13:20, Hugh Williams a écrit :
>> Hi Thomas,
>>
>> Yes, "AdjustVectorSize = 0” as it is the new default in 7.2.2 both in the
>> INI files and if not set, following similar problems display/counting of
>> graphs and queries with long execution times …
>>
>> 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 5 Apr 2016, at 12:03, Thomas Michaux wrote:
>>>
>>> yes it's improving (i added some grpah meanwhile so 46 rows is the correct
>>> number) :
>>>
>>> SPARQL SELECT DISTINCT ?g WHERE { GRAPH ?g { ?s ?p ?o } };
>>> 46 Rows. -- 1337 msec.
>>>
>>> DB.DBA.SPARQL_SELECT_KNOWN_GRAPHS();
>>> 46 Rows. -- 434 msec.
>>>
>>> I had already VectorSize = 1000 in virtuoso.ini but I had
>>> AdjustVectorSize = 1 so changing to 0 has an effect
>>>
>>> We have 232 973 825, read only use case mainly, is it ok to keep
>>> AdjustVectorSize = 0 has documentation
Re: [Virtuoso-users] list graph query performance in V7.2.2 ?
ok, glad to know you're aware of these kind of issues...
don't know if it can help you but before your suggestion (when i had
AdjustVectorSize = 1) i was experimenting "waits" issues (message " *
Monitor: Locks are held for a long time" in the logs), i tried to
investigate with stats query (select top 10 * from sys_l_stat order by
waits desc;) and was only able to notice a lot of wait time was on
VSPX_SESSION index at the top of stats locks results.
...and after your suggestion (AdjustVectorSize = 0), i dont' know if
it's linked, but i noticed these messages in the logs :
12:56:52 OpenLink Virtuoso Universal Server
12:56:52 Version 07.20.3215-pthreads for Linux as of Mar 29 2016
12:56:52 uses parts of OpenSSL, PCRE, Html Tidy
12:57:02 Database version 3126
12:57:02 SQL Optimizer enabled (max 1000 layouts)
12:57:04 Compiler unit is timed at 0.000205 msec
12:57:21 Roll forward started
12:57:21 SQL Error: 23000 : SR175: Uniqueness violation : Violating
unique index VSPX_SESSION on table DB.DBA.VSPX_SESSION. Transaction killed.
12:57:21 In roll forward batch commit failed code 5
12:57:21 Rfwd error: 23000: SR175: Uniqueness violation : Violating
unique index VSPX_SESSION on table DB.DBA.VSPX_SESSION. Transaction killed.
12:57:21 SQL Error: 23000 : SR175: Uniqueness violation : Violating
unique index VSPX_SESSION on table DB.DBA.VSPX_SESSION. Transaction killed.
12:57:21 101 transactions, 10072 bytes replayed (100 %)
12:57:21 Roll forward complete
12:57:22 Checkpoint started
12:57:36 Checkpoint finished, new log is
/usr/local/virtuoso-opensource/var/lib/virtuoso/db/virtuoso20160405125721.trx
12:57:38 HTTP/WebDAV server online at 8890
12:57:38 Server online at (pid 20868)
13:57:40 Checkpoint started
13:57:40 Checkpoint finished, new log is
/usr/local/virtuoso-opensource/var/lib/virtuoso/db/virtuoso20160405135739.trx
14:57:42 Checkpoint started
14:57:42 Checkpoint finished, new log is
/usr/local/virtuoso-opensource/var/lib/virtuoso/db/virtuoso20160405145741.trx
15:57:44 Checkpoint started
15:57:45 Checkpoint finished, new log is
/usr/local/virtuoso-opensource/var/lib/virtuoso/db/virtuoso20160405155743.trx
Thomas
Le 05/04/2016 13:20, Hugh Williams a écrit :
> Hi Thomas,
>
> Yes, "AdjustVectorSize = 0” as it is the new default in 7.2.2 both in the INI
> files and if not set, following similar problems display/counting of graphs
> and queries with long execution times …
>
> 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 5 Apr 2016, at 12:03, Thomas Michaux wrote:
>>
>> yes it's improving (i added some grpah meanwhile so 46 rows is the correct
>> number) :
>>
>> SPARQL SELECT DISTINCT ?g WHERE { GRAPH ?g { ?s ?p ?o } };
>> 46 Rows. -- 1337 msec.
>>
>> DB.DBA.SPARQL_SELECT_KNOWN_GRAPHS();
>> 46 Rows. -- 434 msec.
>>
>> I had already VectorSize = 1000 in virtuoso.ini but I had
>> AdjustVectorSize = 1 so changing to 0 has an effect
>>
>> We have 232 973 825, read only use case mainly, is it ok to keep
>> AdjustVectorSize = 0 has documentation says it will be better to
>> improve performance with = 1 ?
>>
>> Thanks,
>>
>> Thomas
>>
>>
>> Le 05/04/2016 12:52, Hugh Williams a écrit :
>>> Hi Thomas,
>>>
>>> Can you please set the following INI file params in the “[Parameters]”
>>> section, restart Virtuoso and rerun the queries to see if the response time
>>> for the second query and DB.DBA.SPARQL_SELECT_KNOWN_GRAPHS() improves :
>>>
>>> VectorSize = 1000
>>> AdjustVectorSize = 0
>>>
>>>
>>> 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 5 Apr 2016, at 10:24, Thomas Michaux wrote:
Hello,
I found strange that V7.2.2 is faster to answer :
SQL> sparql SELECT ?g COUNT(*) AS ?c { GRAPH ?g {?s ?p ?o.} } GROUP BY ?g
ORDER BY DESC(?c);
37 Rows. -- 2447 msec.
(use all 8 cores and CPU up to 800%)
than
SPARQL SELECT DISTINCT ?g WHERE { GRAPH ?g { ?s ?p ?o } };
37 Rows. -- 522493 msec.
(seem to use only 1 core and CPU up to 100%)
any idea why not should use the first q
Re: [Virtuoso-users] list graph query performance in V7.2.2 ?
Hi Thomas,
Yes, "AdjustVectorSize = 0” as it is the new default in 7.2.2 both in the INI
files and if not set, following similar problems display/counting of graphs
and queries with long execution times …
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 5 Apr 2016, at 12:03, Thomas Michaux wrote:
>
> yes it's improving (i added some grpah meanwhile so 46 rows is the correct
> number) :
>
> SPARQL SELECT DISTINCT ?g WHERE { GRAPH ?g { ?s ?p ?o } };
> 46 Rows. -- 1337 msec.
>
> DB.DBA.SPARQL_SELECT_KNOWN_GRAPHS();
> 46 Rows. -- 434 msec.
>
> I had already VectorSize = 1000 in virtuoso.ini but I had
> AdjustVectorSize = 1 so changing to 0 has an effect
>
> We have 232 973 825, read only use case mainly, is it ok to keep
> AdjustVectorSize = 0 has documentation says it will be better to
> improve performance with = 1 ?
>
> Thanks,
>
> Thomas
>
>
> Le 05/04/2016 12:52, Hugh Williams a écrit :
>> Hi Thomas,
>>
>> Can you please set the following INI file params in the “[Parameters]”
>> section, restart Virtuoso and rerun the queries to see if the response time
>> for the second query and DB.DBA.SPARQL_SELECT_KNOWN_GRAPHS() improves :
>>
>> VectorSize = 1000
>> AdjustVectorSize = 0
>>
>>
>> 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 5 Apr 2016, at 10:24, Thomas Michaux wrote:
>>>
>>> Hello,
>>>
>>> I found strange that V7.2.2 is faster to answer :
>>>
>>>
>>> SQL> sparql SELECT ?g COUNT(*) AS ?c { GRAPH ?g {?s ?p ?o.} } GROUP BY ?g
>>> ORDER BY DESC(?c);
>>> 37 Rows. -- 2447 msec.
>>> (use all 8 cores and CPU up to 800%)
>>>
>>>
>>> than
>>>
>>>
>>> SPARQL SELECT DISTINCT ?g WHERE { GRAPH ?g { ?s ?p ?o } };
>>> 37 Rows. -- 522493 msec.
>>> (seem to use only 1 core and CPU up to 100%)
>>>
>>> any idea why not should use the first query in the Conductor "graph" tab
>>> (DB.DBA.SPARQL_SELECT_KNOWN_GRAPHS) to list the graphs ??
>>>
>>> Thanks,
>>>
>>> Thomas
>>> --
>>> ___
>>> Virtuoso-users mailing list
>>> Virtuoso-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
>
smime.p7s
Description: S/MIME cryptographic signature
--
___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users
Re: [Virtuoso-users] list graph query performance in V7.2.2 ?
yes it's improving (i added some grpah meanwhile so 46 rows is the
correct number) :
SPARQL SELECT DISTINCT ?g WHERE { GRAPH ?g { ?s ?p ?o } };
46 Rows. -- 1337 msec.
DB.DBA.SPARQL_SELECT_KNOWN_GRAPHS();
46 Rows. -- 434 msec.
I had already VectorSize = 1000 in virtuoso.ini but I had
AdjustVectorSize = 1 so changing to 0 has an effect
We have 232 973 825, read only use case mainly, is it ok to keep
AdjustVectorSize = 0 has documentation says it will be better to
improve performance with = 1 ?
Thanks,
Thomas
Le 05/04/2016 12:52, Hugh Williams a écrit :
> Hi Thomas,
>
> Can you please set the following INI file params in the “[Parameters]”
> section, restart Virtuoso and rerun the queries to see if the response time
> for the second query and DB.DBA.SPARQL_SELECT_KNOWN_GRAPHS() improves :
>
> VectorSize = 1000
> AdjustVectorSize = 0
>
>
> 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 5 Apr 2016, at 10:24, Thomas Michaux wrote:
>>
>> Hello,
>>
>> I found strange that V7.2.2 is faster to answer :
>>
>>
>> SQL> sparql SELECT ?g COUNT(*) AS ?c { GRAPH ?g {?s ?p ?o.} } GROUP BY ?g
>> ORDER BY DESC(?c);
>> 37 Rows. -- 2447 msec.
>> (use all 8 cores and CPU up to 800%)
>>
>>
>> than
>>
>>
>> SPARQL SELECT DISTINCT ?g WHERE { GRAPH ?g { ?s ?p ?o } };
>> 37 Rows. -- 522493 msec.
>> (seem to use only 1 core and CPU up to 100%)
>>
>> any idea why not should use the first query in the Conductor "graph" tab
>> (DB.DBA.SPARQL_SELECT_KNOWN_GRAPHS) to list the graphs ??
>>
>> Thanks,
>>
>> Thomas
>> --
>> ___
>> Virtuoso-users mailing list
>> Virtuoso-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
--
___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users
Re: [Virtuoso-users] list graph query performance in V7.2.2 ?
Hi Thomas,
Can you please set the following INI file params in the “[Parameters]” section,
restart Virtuoso and rerun the queries to see if the response time for the
second query and DB.DBA.SPARQL_SELECT_KNOWN_GRAPHS() improves :
VectorSize = 1000
AdjustVectorSize = 0
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 5 Apr 2016, at 10:24, Thomas Michaux wrote:
>
> Hello,
>
> I found strange that V7.2.2 is faster to answer :
>
>
> SQL> sparql SELECT ?g COUNT(*) AS ?c { GRAPH ?g {?s ?p ?o.} } GROUP BY ?g
> ORDER BY DESC(?c);
> 37 Rows. -- 2447 msec.
> (use all 8 cores and CPU up to 800%)
>
>
> than
>
>
> SPARQL SELECT DISTINCT ?g WHERE { GRAPH ?g { ?s ?p ?o } };
> 37 Rows. -- 522493 msec.
> (seem to use only 1 core and CPU up to 100%)
>
> any idea why not should use the first query in the Conductor "graph" tab
> (DB.DBA.SPARQL_SELECT_KNOWN_GRAPHS) to list the graphs ??
>
> Thanks,
>
> Thomas
> --
> ___
> Virtuoso-users mailing list
> Virtuoso-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
smime.p7s
Description: S/MIME cryptographic signature
--
___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users
[Virtuoso-users] list graph query performance in V7.2.2 ?
Hello,
I found strange that V7.2.2 is faster to answer :
SQL> sparql SELECT ?g COUNT(*) AS ?c { GRAPH ?g {?s ?p ?o.} } GROUP BY
?g ORDER BY DESC(?c);
37 Rows. -- *2447 msec.*
(use all 8 cores and CPU up to 800%)
than
SPARQL SELECT DISTINCT ?g WHERE { GRAPH ?g { ?s ?p ?o } };
37 Rows. -- *522493 msec.*
(seem to use only 1 core and CPU up to 100%)
any idea why not should use the first query in the Conductor "graph" tab
(DB.DBA.SPARQL_SELECT_KNOWN_GRAPHS) to list the graphs ??
Thanks,
Thomas
--
___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users
