Hi Thomas, You can use the Virtuoso PL Debugger to see what procedures/statements are running on the server continuously as follows:
$ isql 1111 dba <pwd> -D
OpenLink Interactive PL Debugger (Virtuoso).
Type EXIT to exit, HELP for help
Debug session estabilished to 1111
DEBUG> info threads
@1111: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 <mich...@abes.fr> 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 1111 (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 <mich...@abes.fr> 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 <mich...@abes.fr> 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
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------
_______________________________________________ Virtuoso-users mailing list Virtuoso-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtuoso-users
