Hi Andreas, On the 8891 & 8895 server instances can you connect with the isql PL Debugger ( isql <host:port> dba <dba-password> -D ) and provide the output of running the command “info threads” , which will show the current running threads and procedures associated with them as detailed at:
http://docs.openlinksw.com/virtuoso/pldebugger.html#pldebugger
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 Mar 2016, at 21:31, Hugh Williams <hwilli...@openlinksw.com> wrote:
>
> Hi Andrea,
>
> I haven’t been able reproduce this issue as steps have not been provided to
> recreate, just information to try and analyse the behaviour being
> encountered. If you can provide a copy of your data /databases and HTTP
> recordings of they queries being run, then that would be easiest to
> reproduce the issue ? Failing that if the data is proprietary/secure and
> cannot be provided then there is an option to gather database statistics
> which can be imported locally and the analysed by development to facilitate
> reproducing the effect, as detailed at:
>
>
> http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VirtQueryOptDiagnostic
>
> With regards to the latest sys_l_stat queries detailing locks/waits on the
> database in both sets of queries all the locks/waits are occurring on the
> RO_VAL index of the DB.DBA.RDF_OBJ table:
>
> KEY_TABLE
> INDEX_NAME
> LOCKS WAITS WAIT_PCT DEADLOCKS LOCK_ESC WAIT_MSECS
> VARCHAR NOT NULL
> VARCHAR
> INTEGER INTEGER INTEGER INTEGER INTEGER INTEGER
> _______________________________________________________________________________
>
> DB.DBA.RDF_OBJ
> RO_VAL
> 3431249 1577 0 1141 95 501193384
>
> which is used for storing long “O” (Object) values in the RDF_QUAD table or
> if they have a Free-Text index,see:
>
>
> http://docs.openlinksw.com/virtuoso/rdfdatarepresentation.html#rdfquadtables
>
> Thus do you have many long O ie object/literal values in your datasets or
> have Free-text indexing enabled ? Although I don’t see any use of
> bif:contains which would use the FT index in the sample queries you have
> provided ?
>
> Will have to check with development as to possible cause or prevention of
> these locks on the RO_VAL index …
>
> 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 Mar 2016, at 10:34, Nolle, Andreas <no...@hs-albsig.de> wrote:
>>
>> Dear Hugh,
>>
>> I've again restarted my application and created the top 50 information as
>> well as the corresponding log files at two different times. Please find
>> these files at
>> https://www.dropbox.com/s/6xd1yl6jy8x9pv6/virtuoso_logs.zip?dl=0
>>
>> Please notice that the errors received at the client (my application) vary
>> between:
>> - Virtuoso 22026 Error SR477: Error serializing the value into an ANY column
>> - Virtuoso RDFZZ Error DB.DBA.SPARQL_REXEC('http://141.87.4.8:xxxx/sparql',
>> ...) returned unsupported Content-Type '(NULL)'
>> - Virtuoso 40001 Error SR172: Transaction deadlocked (most of the errors!)
>> and occur still infrequently. So if a query ended with an error but is
>> evaluated some seconds or minutes later, it may happened that the evaluation
>> even works fine.
>>
>> Were you already able to reproduce the described issue regarding the long
>> evaluation times and/or the mentioned errors?
>>
>> Best regards
>> Andy
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Nolle, Andreas
>> Gesendet: Freitag, 4. März 2016 09:10
>> An: 'Hugh Williams' <hwilli...@openlinksw.com>
>> Cc: Kingsley Idehen <kide...@openlinksw.com>;
>> virtuoso-users@lists.sourceforge.net
>> Betreff: AW: [Virtuoso-users] infrequent errors on parallel querying
>>
>> Dear Hugh,
>>
>> now I've run a database integrity check and perform a +crash-dump and
>> restore on Virtuoso instance running at port 8895.
>> After that I've restarted my application and executed the top50 select after
>> some transaction deadlock errors occurred.
>>
>> Please find the top50 information as well as the corresponding log files at
>> https://www.dropbox.com/s/qflp4xtq34o1ioh/locks.zip?dl=0
>>
>> The strange thing is that errors regarding "No ext map for ... in
>> uncommitted blob cpt" are still be there...
>>
>> Please notice that 24 queries are evaluated in parallel via the /sparql end
>> point, i.e. http
>>
>> Best Regards
>> Andy
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval
_______________________________________________ Virtuoso-users mailing list Virtuoso-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtuoso-users
