Hi Hugh,
will the database binary format be backwards compatible, i.e. can we
just copy our 6.1.3-pre database over into 6.1.4's working directory?
Regards,
Martin
On 08.02.2012 16:28, Hugh Williams wrote:
Hi Martin,
Looking at your Virtuoso Server version it appears to be an early
6.1.3
Hi Martin,
will the database binary format be backwards compatible, i.e. can we
just copy our 6.1.3-pre database over into 6.1.4's working directory?
Please read the README.UPGRADE file from the 6.1.4 source tree.
There was a potential problem with some types of XML fragments that
could
Hi Hugh,
virtuoso-t -?
Virtuoso Open Source Edition (multi threaded)
Version 6.1.3-pre1.3127-pthreads as of Sep 23 2010
Compiled for Linux (x86_64-unknown-linux-gnu)
Cheers,
Martin
On 24.01.2012 02:16, Hugh Williams wrote:
Hi Martin,
Assuming an average triple size of 30 bytes, 150 million
Hi Martin,
Looking at your Virtuoso Server version it appears to be an early 6.1.3
pre-release version from Sept 2010, with the 6.1.3 official release having
been made in March 2011, and a 6.1.4 release in Nov 2011. So I would recommend
and upgrade to the latest 6.1.4 release.
Best Regards
Hi Martin,
Assuming an average triple size of 30 bytes, 150 million triples would require
4.5GB of memory ie 562500 (4.5GB / 8K) NumberOfBuffers. Although also how many
triples are there in the Virtuoso Quad stores as that would determine the size
required for hosting to the database working
Hi,
I'd like to rename a graph with about 150 million triples in Virtuoso
Open Source 6.1
The Virtuoso db file has 16GB.
Which is the best way to rename such a big graph? Going through
Conductor/RDF/Graphs/rename or using isql?
Which are the required buffer sizes for renaming the graph?
Hi Martin,
Please see the following tip on rename graphs in Virtuoso, the key for large
graphs being to perform the operation in auto-commit mode (log_enable(3)) to
avoid excessively sized transaction log depleting memory:
Hi Ivan,
I went through the Conductor UI, RDF - Graphs - Rename.
NumberOfBuffers and MaxDirtyBuffers were set to 2359296 (=18GB, on a
machine with 24GB of RAM)
VOS Version is 06.01.3127
Cheers,
Martin
On 23.01.2012 13:01, Ivan Mikhailov wrote:
Hello Martin,
11:37:36 ERROR: Memory low!
Hi Hugh,
I tried as described on the Web page. For a while, memory usage remained
constant, but after a while it suddenly rose and broke:
14:55:30 ERROR: Memory low! Using memory reserve to terminate current
activities properly
14:55:30 ERROR: Current location of the program break
