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
