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
>
> -----Ursprüngliche Nachricht-----
> Von: Hugh Williams [mailto:hwilli...@openlinksw.com]
> Gesendet: Donnerstag, 3. März 2016 02:09
> An: Nolle, Andreas <no...@hs-albsig.de>
> Cc: Kingsley Idehen <kide...@openlinksw.com>;
> virtuoso-users@lists.sourceforge.net
> Betreff: Re: [Virtuoso-users] infrequent errors on parallel querying
>
> Hi Andreas,
>
> The select top 10 * from sys_l_stat order by waits desc; queries from the
> 8891 & 8895 instances do not show an excessive number of waits, only about
> 1990+ waits on the SYS_DAV_QUEUE index. When you ran those queries was the
> system under typical work load ie was the long running query being run at
> the time ? Note you should also run the query a number of time to get a
> sample of the waits as indicated at:
>
> http://docs.openlinksw.com/virtuoso/databaseadmsrv.html#perfdiaglocking
>
> I certainly would have expected a larger number of waits on the 8891 instance
> where the "WARNING: * Monitor: Many lock waits” errors where occurring
> extensively in the log …
>
> You indicate the "transaction deadlock and No ext map for dp 3193852 in
> uncommitted blob cpt” on the 8895 instance only occur when running several
> queries in parallel, so this would be the time to be running the query to
> check for locks/waits. How many of these queries are typically being run in
> parallel ? Also are these queries being executed via the /sparql end point ie
> HTTP or SQL interface ?
>
> 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 2 Mar 2016, at 17:31, Nolle, Andreas <no...@hs-albsig.de> wrote:
>>
>> Dear Hugh,
>>
>> please find the requested information about top50
>> athttps://www.dropbox.com/s/ylrb20ylze38cj6/top50.zip?dl=0
>>
>> Please notice that both errors (transaction deadlock and No ext map for dp
>> 3193852 in uncommitted blob cpt) only occur if I run several queries (of the
>> type already mentioned) in parallel.
>> Since my assumption is that especially the transaction deadlock error
>> is probably related to the long evaluation time, I haven’t restarted my
>> application so far… However, I will run a database integrity check and
>> perform a +crash-dump and restore to eliminate the “uncommitted blob” errors
>> in the next run of my application.
>>
>> Best regards
>> Andy
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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
