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
