[Virtuoso-users] Max columns per table?
Hi: We've been using Virtuoso for a while as an RDF store but are also investigating options to use the SQL server as the vertical storage introduced in 7.x makes it an attractive candidate for medium/big data solutions. It however appears that there is a limit of 200 columns/table which is a significant constraints (we have records with thousands of variables). Can you confirm that this is the case. Is this something that can be configured or a hard limit? best *P -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ Virtuoso-users mailing list Virtuoso-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtuoso-users
Re: [Virtuoso-users] Max columns per table?
Hugh: That's correct. This is with 7.1 windows but this fact is documented under 6.1.4 Limits in http://docs.openlinksw.com/virtuoso/dbadm.html (the section does not show as a HTML table but contains" Columns per row 200 ") I think the column store SQL could provider a competitive option to entry level big data solutions or for medium data use cases, but this limit if correct would be a barrier to adoption. best *P On 5/13/14, 3:14 AM, Hugh Williams wrote: > Hi Pascal, > > By vertical storage I presume you mean column store ? Will have to > check with the development if such a limit still exists on columns/per > table. What is the version you are using (virtuoso-t -?) ? > > 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 12 May 2014, at 22:18, Pascal Heus <mailto:pascal.h...@mtna.us>> wrote: > >> Hi: >> We've been using Virtuoso for a while as an RDF store but are also >> investigating options to use the SQL server as the vertical storage >> introduced in 7.x makes it an attractive candidate for medium/big data >> solutions. It however appears that there is a limit of 200 columns/table >> which is a significant constraints (we have records with thousands of >> variables). Can you confirm that this is the case. Is this something >> that can be configured or a hard limit? >> best >> *P >> >> -- >> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE >> Instantly run your Selenium tests across 300+ browser/OS combos. >> Get unparalleled scalability from the best Selenium testing platform >> available >> Simple to use. Nothing to install. Get started now for free." >> http://p.sf.net/sfu/SauceLabs >> ___ >> Virtuoso-users mailing list >> Virtuoso-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/virtuoso-users > -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs___ Virtuoso-users mailing list Virtuoso-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtuoso-users
[Virtuoso-users] Diagnosing server termination
We're running Virtusoso 07.10.3207 on a NT 2008 R2 server with 8Gb memory and two CPU cores. The server last night stopped abruptly and the only trace I could find is in the Windows Event log: "The OpenLink Virtuoso Server service terminated unexpectedly. It has done this 1 time(s)." Server is used by by a webapp and had been runnign for a couple of days. A light SPARQL query was submitted a couple of seconds before. What's the best approach to start diagnosing the issue (log levels, debug, etc.)? best *P -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Virtuoso-users mailing list Virtuoso-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtuoso-users
[Virtuoso-users] Unlinked the temp db file virtuoso-temp.db
When our Virtuoso servers restarts, I noticed the following entry in the DB log: Unlinked the temp db file virtuoso-temp.db as its size (24MB) was greater than TempDBSize INI (10MB) Does this has any impact on operation/performance down the road? Should I set the [Parameters] TempDBSize to for example 5000? best *P -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Virtuoso-users mailing list Virtuoso-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtuoso-users
[Virtuoso-users] Virtuoso abrupt termination
We're running Virtusoso 07.10.3207 on a NT 2008 R2 cloud server with 8Gb memory and two CPU cores. The server stopped abruptly with following in the Windows event. Does this indicate anything regarding the potential cause of the problem? This is not the first time this happens. As mentioned in previous post, it there a recommended way to log/debug/diagnose/monitor the server? best *P Faulting application name: virtuoso-t.exe, version: 7.0.1.3207, time stamp: 0x53025c94 Faulting module name: virtuoso-t.exe, version: 7.0.1.3207, time stamp: 0x53025c94 Exception code: 0xc005 Fault offset: 0x004a721c Faulting process id: 0xcd0 Faulting application start time: 0x01cf8ee1599f1056 Faulting application path: c:\software\virtuoso\bin\virtuoso-t.exe Faulting module path: c:\software\virtuoso\bin\virtuoso-t.exe Report Id: 8cd934d9-0558-11e4-a5af-005056bb67de -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Virtuoso-users mailing list Virtuoso-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtuoso-users
Re: [Virtuoso-users] Virtuoso abrupt termination
uld be in the Virtuoso > server log file "virtuoso.log" in the database directory where there > maybe an indication as to why , if the problem occurred in Virtuoso > itself. You can also enable more verbose logging of server activities > to the virtuoso log file using the trace_on() function as detailed at: > > http://docs.openlinksw.com/virtuoso/fn_trace_on.html > > Although not it full tracing is turned on it will be very verbose and > write a lot of information to the log, thus you should turn it off > when done with the trace_off function ... > > 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 10 Jul 2014, at 09:20, Pascal Heus <mailto:pascal.h...@mtna.us>> wrote: > >> We're running Virtusoso 07.10.3207 on a NT 2008 R2 cloud server with 8Gb >> memory and two CPU cores. >> The server stopped abruptly with following in the Windows event. Does >> this indicate anything regarding the potential cause of the problem? >> This is not the first time this happens. As mentioned in previous post, >> it there a recommended way to log/debug/diagnose/monitor the server? >> best >> *P >> >>Faulting application name: virtuoso-t.exe, version: 7.0.1.3207, time >> stamp: 0x53025c94 >>Faulting module name: virtuoso-t.exe, version: 7.0.1.3207, time >> stamp: 0x53025c94 >>Exception code: 0xc005 >>Fault offset: 0x004a721c >>Faulting process id: 0xcd0 >>Faulting application start time: 0x01cf8ee1599f1056 >>Faulting application path: c:\software\virtuoso\bin\virtuoso-t.exe >>Faulting module path: c:\software\virtuoso\bin\virtuoso-t.exe >>Report Id: 8cd934d9-0558-11e4-a5af-005056bb67de >> >> -- >> Open source business process management suite built on Java and Eclipse >> Turn processes into business applications with Bonita BPM Community >> Edition >> Quickly connect people, data, and systems into organized workflows >> Winner of BOSSIE, CODIE, OW2 and Gartner awards >> http://p.sf.net/sfu/Bonitasoft >> ___ >> 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
Re: [Virtuoso-users] Virtuoso abrupt termination
Hugh: Just to let you know our development server crashed as well today, so doesn't seem to be a server specific issue. Maybe something wrong we're doing in our java code? best *P On 7/13/14, 9:14 AM, Pascal Heus wrote: > Hugh: > We a few more crashes and turned tracing on. Don't see anything in > particular right before the server terminates but not sure either how > to interpret the trace either. Is there any particular trace option we > should turn on/off. > We do see lots of transactions rollback/restart/logout groups at the > end and throughout the log, along with numerous begin/commit/restart. > I noticed that the same transaction ID may appear multiple time. > I'll sent you shortly an email with a link to download the full log if > that helps. Any suggestion as to what we could do next? > Note that the puzzling part is that we experience this on the staging > server, our development server is stable. The differences I can think > of are two CPU instead of one, a bit more memory (8Gb vs 4Gb), and > hosting company. > best > *P > > ... > 18:04:10 LTRS_1 cms 172.23.79.34 :1077 Rollback transact > 00018D9B3990 0 > 18:04:10 LTRS_2 cms 172.23.79.34 :1077 Restart transact > 00018D9B3990 > 18:04:10 USER_0 cms 172.23.79.34 :1077 logout > 18:04:10 LTRS_1 cms 172.23.79.34 :1078 Rollback transact > 000192DFA590 0 > 18:04:10 LTRS_2 cms 172.23.79.34 :1078 Restart transact > 000192DFA590 > 18:04:10 USER_0 cms 172.23.79.34 :1078 logout > 18:04:10 LTRS_1 cms 172.23.79.34 :1080 Rollback transact > 000192DF98C0 0 > 18:04:10 LTRS_2 cms 172.23.79.34 :1080 Restart transact > 000192DF98C0 > 18:04:10 USER_0 cms 172.23.79.34 :1080 logout > 18:04:10 LTRS_1 cms 172.23.79.34 :1081 Rollback transact > 0001AD117060 0 > 18:04:10 LTRS_2 cms 172.23.79.34 :1081 Restart transact > 0001AD117060 > 18:04:10 USER_0 cms 172.23.79.34 :1081 logout > 18:04:10 LTRS_1 cms 172.23.79.34 :1079 Rollback transact > 0DF5B990 0 > 18:04:10 LTRS_2 cms 172.23.79.34 :1079 Restart transact > 0DF5B990 > 18:04:10 USER_0 cms 172.23.79.34 :1079 logout > 18:04:10 LTRS_1 cms 172.23.79.34 :1082 Rollback transact > 0001A46E7B30 0 > 18:04:10 LTRS_2 cms 172.23.79.34 :1082 Restart transact > 0001A46E7B30 > 18:04:10 USER_0 cms 172.23.79.34 :1082 logout > 18:04:10 LTRS_1 cms 172.23.79.34 :1083 Rollback transact > 0001D03793E0 0 > 18:04:10 LTRS_2 cms 172.23.79.34 :1083 Restart transact > 0001D03793E0 > 18:04:10 USER_0 cms 172.23.79.34 :1083 logout > 18:04:10 LTRS_1 cms 172.23.79.34 :1084 Rollback transact > 00018D9B43D0 0 > 18:04:10 LTRS_2 cms 172.23.79.34 :1084 Restart transact > 00018D9B43D0 > 18:04:10 USER_0 cms 172.23.79.34 :1084 logout > 18:04:10 LTRS_1 cms 172.23.79.34 :1085 Rollback transact > 0001D037B530 0 > 18:04:10 LTRS_2 cms 172.23.79.34 :1085 Restart transact > 0001D037B530 > 18:04:10 USER_0 cms 172.23.79.34 :1085 logout > 18:04:10 LTRS_1 cms 172.23.79.34 :1086 Rollback transact > 0DF5C140 0 > 18:04:10 LTRS_2 cms 172.23.79.34 :1086 Restart transact > 0DF5C140 > 18:04:10 USER_0 cms 172.23.79.34 :1086 logout > 18:04:10 LTRS_1 cms 172.23.79.34 :1087 Rollback transact > 000193EBC460 0 > 18:04:10 LTRS_2 cms 172.23.79.34 :1087 Restart transact > 000193EBC460 > 18:04:10 USER_0 cms 172.23.79.34 :1087 logout > 18:04:10 LTRS_1 cms 172.23.79.34 :1089 Rollback transact > 000192DF8440 0 > 18:04:10 LTRS_2 cms 172.23.79.34 :1089 Restart transact > 000192DF8440 > 18:04:10 LTRS_1 cms 172.23.79.34 :1088 Rollback transact > 0001D2141FB0 0 > 18:04:10 LTRS_2 cms 172.23.79.34 :1088 Restart transact > 0001D2141FB0 > 18:04:10 USER_0 cms 172.23.79.34 :1089 logout > 18:04:10 USER_0 cms 172.23.79.34 :1088 logout > 18:04:10 LTRS_1 cms 172.23.79.34 :1091 Rollback transact > 0001D21408A0 0 > 18:04:10 LTRS_2 cms 172.23.79.34 :1091 Restart transact > 0001D21408A0 > 18:04:10 USER_0 cms 172.23.79.34 :1091 logout > 18:04:10 LTRS_1 cms 172.23.79.34 :1090 Rollback transact > 00016CD6ED40 0 > 18:04:10 LTRS_2 cms 172.23.79.34 :1090 Restart transact > 00016CD6ED40 > 18:04:10 USER_0 cms 172.23.79.34 :1090 logout > 18:04:10 LTRS_1 cms 172.23.79.34 :1092 Rollback transact > 00018F39AFD0 0 > 18:04:10 LTRS_2 cms 172.23.79.34 :1092 Restart transact > 00018F39AFD0 > 18:04:10 USER_0 cms 172.23.79.34 :1092 logout > 18:04:10 LTRS_1 cms 172.23.79.34 :1093 Rollback transact > 0001D037AD80 0 > 18:04:10 LTRS_2 cms 172.23.79.34 :1093 Restart transact
Re: [Virtuoso-users] Virtuoso abrupt termination
Hugh: Thanks for the feedback. So all the entries we see in the log are expected (particularly the transactions restart/rollback/etc.)? Anything else we could do to monitor/trace activities? We'll deploy the latest windows release asap and let you know how it fares. best *P On 7/16/14, 1:10 PM, Hugh Williams wrote: > Hi Pascal, > > Unfortunately the log does not provide any information as to the cause > of the crash. > > The latest Windows open source Virtuoso 7.1 binary can be downloaded from: > > ftp://download.openlinksw.com/support/db/virtuoso-t.zip > > Simply run a checkpoint, shutdown Virtuoso, unzip and replace the > current virtuoso-t.exe file with this one and restart. > > The version details being: > > ..\bin\virtuoso -t -? > Virtuoso Open Source Edition (multi threaded) > Version 7.1.0.3211-threads as of Jul 10 2014 > Compiled for Win64 (x86_64-generic-win-64) > Copyright (C) 1998-2014 OpenLink Software > > Can you update your database to this version and see if the problem > persists ... > > 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 14 Jul 2014, at 20:25, Pascal Heus <mailto:pascal.h...@mtna.us>> wrote: > >> Hugh: >> Just to let you know our development server crashed as well today, so >> doesn't seem to be a server specific issue. Maybe something wrong >> we're doing in our java code? >> best >> *P >> >> On 7/13/14, 9:14 AM, Pascal Heus wrote: >>> Hugh: >>> We a few more crashes and turned tracing on. Don't see anything in >>> particular right before the server terminates but not sure either >>> how to interpret the trace either. Is there any particular trace >>> option we should turn on/off. >>> We do see lots of transactions rollback/restart/logout groups at the >>> end and throughout the log, along with numerous >>> begin/commit/restart. I noticed that the same transaction ID may >>> appear multiple time. >>> I'll sent you shortly an email with a link to download the full log >>> if that helps. Any suggestion as to what we could do next? >>> Note that the puzzling part is that we experience this on the >>> staging server, our development server is stable. The differences I >>> can think of are two CPU instead of one, a bit more memory (8Gb vs >>> 4Gb), and hosting company. >>> best >>> *P >>> >>> ... >>> 18:04:10 LTRS_1 cms 172.23.79.34 :1077 Rollback transact >>> 00018D9B3990 0 >>> 18:04:10 LTRS_2 cms 172.23.79.34 :1077 Restart transact >>> 00018D9B3990 >>> 18:04:10 USER_0 cms 172.23.79.34 :1077 logout >>> 18:04:10 LTRS_1 cms 172.23.79.34 :1078 Rollback transact >>> 000192DFA590 0 >>> 18:04:10 LTRS_2 cms 172.23.79.34 :1078 Restart transact >>> 000192DFA590 >>> 18:04:10 USER_0 cms 172.23.79.34 :1078 logout >>> 18:04:10 LTRS_1 cms 172.23.79.34 :1080 Rollback transact >>> 000192DF98C0 0 >>> 18:04:10 LTRS_2 cms 172.23.79.34 :1080 Restart transact >>> 000192DF98C0 >>> 18:04:10 USER_0 cms 172.23.79.34 :1080 logout >>> 18:04:10 LTRS_1 cms 172.23.79.34 :1081 Rollback transact >>> 0001AD117060 0 >>> 18:04:10 LTRS_2 cms 172.23.79.34 :1081 Restart transact >>> 0001AD117060 >>> 18:04:10 USER_0 cms 172.23.79.34 :1081 logout >>> 18:04:10 LTRS_1 cms 172.23.79.34 :1079 Rollback transact >>> 0DF5B990 0 >>> 18:04:10 LTRS_2 cms 172.23.79.34 :1079 Restart transact >>> 0DF5B990 >>> 18:04:10 USER_0 cms 172.23.79.34 :1079 logout >>> 18:04:10 LTRS_1 cms 172.23.79.34 :1082 Rollback transact >>> 0001A46E7B30 0 >>> 18:04:10 LTRS_2 cms 172.23.79.34 :1082 Restart transact >>> 0001A46E7B30 >>> 18:04:10 USER_0 cms 172.23.79.34 :1082 logout >>> 18:04:10 LTRS_1 cms 172.23.79.34 :1083 Rollback transact >>> 0001D03793E0 0 >>> 18:04:10 LTRS_2 cms 172.23.79.34 :1083 Restart transact >>> 0001D03793E0 >>> 18:04:10 USER_0 cms 172.23.79.34 :1083 logout >>> 18:04:10 LTRS_1
Re: [Virtuoso-users] Virtuoso abrupt termination
High: Finally got to look into this. When I simply replace our existing virtuoso-t.exe (3207) with the latest one you provided (3211), I get an MSVCR110.dll missing error which seem to be part if Visual Studio 2011 or 2012. This can be retrieved at http://www.microsoft.com/en-us/download/details.aspx?id=30679 I'll try to this shortly distribution shortly. Did you recently upgrade to a more recent version os VS? Note that your web site page below points to the 2010 distribution: http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VOSUsageWindows best *P On 7/16/14, 1:10 PM, Hugh Williams wrote: > Hi Pascal, > > Unfortunately the log does not provide any information as to the cause > of the crash. > > The latest Windows open source Virtuoso 7.1 binary can be downloaded from: > > ftp://download.openlinksw.com/support/db/virtuoso-t.zip > > Simply run a checkpoint, shutdown Virtuoso, unzip and replace the > current virtuoso-t.exe file with this one and restart. > > The version details being: > > ..\bin\virtuoso -t -? > Virtuoso Open Source Edition (multi threaded) > Version 7.1.0.3211-threads as of Jul 10 2014 > Compiled for Win64 (x86_64-generic-win-64) > Copyright (C) 1998-2014 OpenLink Software > > Can you update your database to this version and see if the problem > persists ... > > 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 14 Jul 2014, at 20:25, Pascal Heus <mailto:pascal.h...@mtna.us>> wrote: > >> Hugh: >> Just to let you know our development server crashed as well today, so >> doesn't seem to be a server specific issue. Maybe something wrong >> we're doing in our java code? >> best >> *P >> >> On 7/13/14, 9:14 AM, Pascal Heus wrote: >>> Hugh: >>> We a few more crashes and turned tracing on. Don't see anything in >>> particular right before the server terminates but not sure either >>> how to interpret the trace either. Is there any particular trace >>> option we should turn on/off. >>> We do see lots of transactions rollback/restart/logout groups at the >>> end and throughout the log, along with numerous >>> begin/commit/restart. I noticed that the same transaction ID may >>> appear multiple time. >>> I'll sent you shortly an email with a link to download the full log >>> if that helps. Any suggestion as to what we could do next? >>> Note that the puzzling part is that we experience this on the >>> staging server, our development server is stable. The differences I >>> can think of are two CPU instead of one, a bit more memory (8Gb vs >>> 4Gb), and hosting company. >>> best >>> *P >>> >>> ... >>> 18:04:10 LTRS_1 cms 172.23.79.34 :1077 Rollback transact >>> 00018D9B3990 0 >>> 18:04:10 LTRS_2 cms 172.23.79.34 :1077 Restart transact >>> 00018D9B3990 >>> 18:04:10 USER_0 cms 172.23.79.34 :1077 logout >>> 18:04:10 LTRS_1 cms 172.23.79.34 :1078 Rollback transact >>> 000192DFA590 0 >>> 18:04:10 LTRS_2 cms 172.23.79.34 :1078 Restart transact >>> 000192DFA590 >>> 18:04:10 USER_0 cms 172.23.79.34 :1078 logout >>> 18:04:10 LTRS_1 cms 172.23.79.34 :1080 Rollback transact >>> 000192DF98C0 0 >>> 18:04:10 LTRS_2 cms 172.23.79.34 :1080 Restart transact >>> 000192DF98C0 >>> 18:04:10 USER_0 cms 172.23.79.34 :1080 logout >>> 18:04:10 LTRS_1 cms 172.23.79.34 :1081 Rollback transact >>> 0001AD117060 0 >>> 18:04:10 LTRS_2 cms 172.23.79.34 :1081 Restart transact >>> 0001AD117060 >>> 18:04:10 USER_0 cms 172.23.79.34 :1081 logout >>> 18:04:10 LTRS_1 cms 172.23.79.34 :1079 Rollback transact >>> 0DF5B990 0 >>> 18:04:10 LTRS_2 cms 172.23.79.34 :1079 Restart transact >>> 0DF5B990 >>> 18:04:10 USER_0 cms 172.23.79.34 :1079 logout >>> 18:04:10 LTRS_1 cms 172.23.79.34 :1082 Rollback transact >>> 0001A46E7B30 0 >>> 18:04:10 LTRS_2 cms 172.23.79.34 :1082 Restart transact >>> 0001A46E7B30 >>> 18:04:10 USER_0 cms 172.23.79.34 :1082 logout >>> 18
[Virtuoso-users] Dashboard question
Have a couple of questions on the Conductor Sysadmin dashboard related to the client connection counts: - Is it correct that the "clients connected" is the number if connections opened and closed since server start up? - Under clients, the number of connections I see there seem to be higher than the count I would expect. I would essentially expect this to be equal to 1 from an idle web application server using virtuoso as back end (though the Java virtuoso pool). But this is often 10+. Where might the other counts be coming from? I assume one if from the conductor UI itself. - Noted as well as this goes up by 1 eachg time I reload the conductor dashboard UI. In general, when are these statistics updated? - Is there an equivalent isql function that could also give mo more details on the individual connections? much appreciated *P -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk ___ Virtuoso-users mailing list Virtuoso-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtuoso-users
[Virtuoso-users] mp_mmap_clocks over 10% of real time
Our VOS7 went down today on our development system. About 12 hours prior to the crash following messages started to show in the log: Monitor: The mp_mmap_clocks over 10% of real time This comes from the monitor.c file and seem memory related. Could you clarify what this means? We suspect our server was running out of virtual memory or swapping too much. We're testing with a 5-6Gb database, using Version 07.10.3211-threads for Win64 as of Jul 10 2014 running on NT2008 w/1-core 4Gb RAM (AWS t1.medium instance). Last restart was Jan 8th (25 days ago)... best *P -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Virtuoso-users mailing list Virtuoso-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtuoso-users
[Virtuoso-users] 7.2 MacOSX issue
Jst checked out latest version fron GIT and built on MacOSX using same
procedure as usual which consists in:
git pull
make clean
./autogen.sh
CFLAGS="-O2 -m64"
export CFLAGS
./configure
make
I then wiped out my current install and called
make install
When I try to run virtuoso-t, I get the log below.
Note that the log is showing
07.10.3211-pthreads for Darwin as of Feb 12 2015
but if I run virtuoso-t -version I see:
Virtuoso Open Source Edition (Column Store) (multi threaded)
Version 7.2.1-dev.3211-pthreads as of Feb 12 2015
Compiled for Darwin (x86_64-apple-darwin14.1.0)
Copyright (C) 1998-2015 OpenLink Software
Any suggestion?
thanks
*P
Thu Feb 12 2015
23:22:52 { Loading plugin 1: Type `plain', file `wikiv' in
`/usr/local/virtuoso-opensource/lib/virtuoso/hosting'
23:22:52 FAILED plugin 1: Unable to locate file }
23:22:52 { Loading plugin 2: Type `plain', file `mediawiki' in
`/usr/local/virtuoso-opensource/lib/virtuoso/hosting'
23:22:52 FAILED plugin 2: Unable to locate file }
23:22:52 { Loading plugin 3: Type `plain', file `creolewiki' in
`/usr/local/virtuoso-opensource/lib/virtuoso/hosting'
23:22:52 FAILED plugin 3: Unable to locate file }
23:22:52 OpenLink Virtuoso Universal Server
23:22:52 Version 07.10.3211-pthreads for Darwin as of Feb 12 2015
23:22:52 uses parts of OpenSSL, PCRE, Html Tidy
23:22:52 SQL Optimizer enabled (max 1000 layouts)
23:22:53 Compiler unit is timed at 0.000460 msec
23:22:55 built-in procedure "repl_undot_name" overruled by the RDBMS
23:22:58 Checkpoint started
23:22:58 Roll forward started
23:22:58 Roll forward complete
23:22:58 Checkpoint started
23:22:58 Checkpoint finished, log reused
23:22:58 Checkpoint started
23:22:58 Checkpoint finished, log reused
23:22:59 Checkpoint started
23:22:59 Checkpoint finished, log reused
23:22:59 Checkpoint started
23:22:59 Checkpoint finished, log reused
23:22:59 Checkpoint started
23:22:59 Checkpoint finished, log reused
23:23:00 PL LOG: Installing Virtuoso Conductor version 1.00.8740 (DAV)
23:23:00 Checkpoint started
23:23:00 Checkpoint finished, log reused
23:23:00 0 virtuoso-t 0x00010483ab46
gpf_notice + 70
23:23:00 1 virtuoso-t 0x00010441cc76
page_apply + 166
23:23:00 2 virtuoso-t 0x0001045eec25
upd_refit_row + 213
23:23:00 3 virtuoso-t 0x0001045effa1
update_node_run_1 + 3089
23:23:00 4 virtuoso-t 0x0001045cb245
update_node_vec_run + 1157
23:23:00 5 virtuoso-t 0x0001045abeb1
trig_wrapper + 97
23:23:00 6 virtuoso-t 0x0001045f0f5c
update_node_input + 556
23:23:00 7 virtuoso-t 0x000104590144
qn_input + 404
23:23:00 8 virtuoso-t 0x0001045904f5
qn_ts_send_output + 293
23:23:00 9 virtuoso-t 0x000104593066
table_source_input + 2950
23:23:00 10 virtuoso-t 0x000104590144
qn_input + 404
23:23:00 11 virtuoso-t 0x0001045903a3
qn_send_output + 291
23:23:00 12 virtuoso-t 0x0001045c9921
set_ctr_vec_input + 897
23:23:00 13 virtuoso-t 0x000104590144
qn_input + 404
23:23:00 14 virtuoso-t 0x00010455fc24
subq_next + 260
23:23:00 15 virtuoso-t 0x00010455fdb6
ins_subq + 134
23:23:00 16 virtuoso-t 0x00010456486e
code_vec_run_1 + 1790
23:23:00 17 virtuoso-t 0x000104590137
qn_input + 391
23:23:00 18 virtuoso-t 0x00010459a43c
qr_subq_exec + 1436
23:23:00 19 virtuoso-t 0x0001045abb23
trig_call_1 + 899
23:23:00 20 virtuoso-t 0x0001045ac03e
trig_wrapper + 494
23:23:00 21 virtuoso-t 0x000104594057
insert_node_input + 103
23:23:00 22 virtuoso-t 0x000104590144
qn_input + 404
23:23:00 23 virtuoso-t 0x000104562813
ins_qnode + 387
23:23:00 24 virtuoso-t 0x000104564886
code_vec_run_1 + 1814
23:23:00 25 virtuoso-t 0x000104590137
qn_input + 391
23:23:00 26 virtuoso-t 0x00010459a43c
qr_subq_exec + 1436
23:23:00 27 virtuoso-t 0x00010455e161
ins_call + 2289
23:23:00 28 virtuoso-t 0x000104564709
code_vec_run_1 + 1433
23:23:00 29 virtuoso-t 0x000104590137
qn_input + 391
23:23:00 30 virtuoso-t 0x00010459a43c
qr_subq_exec + 1436
23:23:00 31 virtuoso-t 0x00010455e161
ins_call + 2289
23:23:00 32 virtuoso-t 0x000104564709
code_vec_run_1 + 1433
23:23:00 33 virtuoso-t
Re: [Virtuoso-users] 7.2 MacOSX issue
Marc-Antoine: Thanks for the feedback, this is however a bit cryptic for me. Can't seem to run diff --git etc. What does this accomplish? thanks *P On 2/12/15 11:35 PM, Marc-Antoine Parent wrote: > Yes…. on my machine, I did this: > > diff --git a/binsrc/virtuoso/viunix.c b/binsrc/virtuoso/viunix.c > index 4076248..bba1592 100644 > --- a/binsrc/virtuoso/viunix.c > +++ b/binsrc/virtuoso/viunix.c > @@ -572,7 +572,7 @@ main (int argc, char **argv) > >process_exit_hook = viunix_terminate; > > - thread_initial (6); > + thread_initial (8); >if (!background_sem) > background_sem = semaphore_allocate (0); > > -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Virtuoso-users mailing list Virtuoso-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtuoso-users
Re: [Virtuoso-users] 7.2 MacOSX issue
Yup, that makes sense. Thanks for the clarification (brushing on my diff skills...)! All working fine now. Also found the thread around this: https://github.com/openlink/virtuoso-opensource/issues/277 Just noted that the conductor UI and log entries show 07.10.3211 though virtuoso-t -version displays Version 7.2.1-dev.3211-pthreads as of Feb 13 2015 cheers *P On 2/13/15 2:19 PM, Marc-Antoine Parent wrote: > Sorry, this was written fast and I assumed familiarity with the diff format. > It is just showing an adjustment I had to make in the virtuoso code to make > it run on MacOSX. > So open binsrc/virtuoso/viunix.c b/binsrc/virtuoso/viunix.c in a text editor, > change the value of thread_initial (around line 530) from 6 to 8, > recompile, and it should work. > Hope that helps, > Marc-Antoine > > >> Le 2015-02-13 à 08:12, Pascal Heus a écrit : >> >> Marc-Antoine: >> Thanks for the feedback, this is however a bit cryptic for me. Can't >> seem to run diff --git etc. >> What does this accomplish? >> thanks >> *P >> >> On 2/12/15 11:35 PM, Marc-Antoine Parent wrote: >>> Yes…. on my machine, I did this: >>> >>> diff --git a/binsrc/virtuoso/viunix.c b/binsrc/virtuoso/viunix.c >>> index 4076248..bba1592 100644 >>> --- a/binsrc/virtuoso/viunix.c >>> +++ b/binsrc/virtuoso/viunix.c >>> @@ -572,7 +572,7 @@ main (int argc, char **argv) >>> >>> process_exit_hook = viunix_terminate; >>> >>> - thread_initial (6); >>> + thread_initial (8); >>> if (!background_sem) >>> background_sem = semaphore_allocate (0); >>> >>> > -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Virtuoso-users mailing list Virtuoso-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtuoso-users
Re: [Virtuoso-users] 7.2 MacOSX issue
Hugh: thanks for the update, let me know if I can help testing from my end. best *P On 2/16/15 12:36 AM, Hugh Williams wrote: > Hi Pascal, > > We are going to check this "page_apply called with not enough stack” > crash on Yosemite again to see if 80K for the initial thread size is > large enough or devise a better fix. > > Note, there was a hotfix applied to the stable and develop 7 open > source git archives over the weekend to fix the 7.2 version issue, > which is now correct: > > VIRTMAIN@Hughs-MBP:~$ git status > On branch stable/7 > Your branch is up-to-date with 'origin/stable/7'. > > VIRTMAIN@Hughs-MBP:~$ binsrc/virtuoso/virtuoso-t -? > Virtuoso Open Source Edition (Column Store) (multi threaded) > Version 7.2.0.3212-pthreads as of Feb 15 2015 > Compiled for Darwin (x86_64-apple-darwin14.0.0) > Copyright (C) 1998-2015 OpenLink Software > > 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 13 Feb 2015, at 15:57, Pascal Heus > <mailto:pascal.h...@mtna.us>> wrote: >> >> Yup, that makes sense. Thanks for the clarification (brushing on my diff >> skills...)! All working fine now. >> Also found the thread around this: >> https://github.com/openlink/virtuoso-opensource/issues/277 >> >> Just noted that the conductor UI and log entries show 07.10.3211 >> though virtuoso-t -version displays Version 7.2.1-dev.3211-pthreads as >> of Feb 13 2015 >> >> cheers >> *P >> >> On 2/13/15 2:19 PM, Marc-Antoine Parent wrote: >>> Sorry, this was written fast and I assumed familiarity with the diff >>> format. It is just showing an adjustment I had to make in the >>> virtuoso code to make it run on MacOSX. >>> So open binsrc/virtuoso/viunix.c b/binsrc/virtuoso/viunix.c in a >>> text editor, change the value of thread_initial (around line 530) >>> from 6 to 8, recompile, and it should work. >>> Hope that helps, >>> Marc-Antoine >>> >>> >>>> Le 2015-02-13 à 08:12, Pascal Heus a écrit : >>>> >>>> Marc-Antoine: >>>> Thanks for the feedback, this is however a bit cryptic for me. Can't >>>> seem to run diff --git etc. >>>> What does this accomplish? >>>> thanks >>>> *P >>>> >>>> On 2/12/15 11:35 PM, Marc-Antoine Parent wrote: >>>>> Yes…. on my machine, I did this: >>>>> >>>>> diff --git a/binsrc/virtuoso/viunix.c b/binsrc/virtuoso/viunix.c >>>>> index 4076248..bba1592 100644 >>>>> --- a/binsrc/virtuoso/viunix.c >>>>> +++ b/binsrc/virtuoso/viunix.c >>>>> @@ -572,7 +572,7 @@ main (int argc, char **argv) >>>>> >>>>> process_exit_hook = viunix_terminate; >>>>> >>>>> - thread_initial (6); >>>>> + thread_initial (8); >>>>> if (!background_sem) >>>>>background_sem = semaphore_allocate (0); >>>>> >>>>> >>> >> >> >> -- >> Dive into the World of Parallel Programming. The Go Parallel Website, >> sponsored by Intel and developed in partnership with Slashdot Media, >> is your >> hub for all things parallel software development, from weekly thought >> leadership blogs to news, videos, case studies, tutorials and more. >> Take a >> look and join the conversation now. http://goparallel.sourceforge.net/ >> ___ >> Virtuoso-users mailing list >> Virtuoso-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/virtuoso-users > -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Virtuoso-users mailing list Virtuoso-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtuoso-users
