compared with
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (21)

View Page History
This will return the repository ID and type, followed by name-value pairs of configuration data for SAIL repositories, including the SAIL type - "owlim:Sail" for GraphDB-SE and "swiftowlim:Sail" for GraphDB-Lite. GraphDB-Enterprise master nodes are not SAIL repositories and have the type "owlim:ReplicationCluster".

If you uncomment the FILTER clause, you can substitute a repository id to get the configuration just for that repository.

h5. How do I change the configuration of an a GraphDB Sesame repository after it has been created?

There is no easy generic way of changing the configuration - it is stored in the SYSTEM repository created and maintained by Sesame. However, GraphDB allows overriding of these parameters by specifying the parameter values as JVM options. For instance, by passing \-Dcache-memory=1g option to the JVM, GraphDB-SE will read it and use its value to override whatever was configured by the .ttl file. This is convenient for temporary set-ups that require easy and fast configuration change, e.g. for experimental purposes.

Changing the configuration in the SYSTEM repository is trickier, because the configurations are usually structured using blank node identifiers - identifiers, which are always unique, so attempting to modify a statement with a blank node by using the same blank node identifier will fail. However, this can be achieved with SPARQL UPDATE using a DELETE-INSERT-WHERE command as follows:


Modify the last three lines of the update command to specify the repository ID, the parameter, and the new value. Then execute against the SYSTEM repository. In this example, the enable-context-index is changed, but there are other parameters that can not be changed once the repository is created, e.g. the rule-set (in the case of GraphDB-SE).

A restart of Sesame/GraphDB is required. If deployed using Tomcat, then the easiest way is just to restart Tomcat itself.

h5. How can I find out the exact version number of GraphDB-SE/GraphDB-Enterprise?
The major/minor version and build number make up part of the GraphDB distribution zip file name. The embedded owlim jar file has the major and minor version numbers appended.

In addition, at start up, GraphDB-SE and GraphDB-Enterprise worker nodes will log the full version number in an INFO logger message, e.g. {{OwlimSchemaRepository: version: 5.6, revision: 6864}}

The following DESCRIBE query:

will return pseudo-triples providing information on various GraphDB states, including: the number of triples (total and explicit), storage space (used and free), commits (total and if one is in progress), the repository signature, and the build number of software.

h5. How can the rule set be changed?

BIND( "new_repository_name" AS ?new_name ) . }
# Rename the folder for this repository oin the file system
#* mv /usr/share/tomcat6/.aduna/openrdf-sesame/repositories/OLD_NAME /usr/share/tomcat6/.aduna/openrdf-sesame/repositories/NEW_NAME (linux/unix)
#* The location for the 'repositories' folder under Windows varies depending on the version of Windows and the installation method for Tomcat - some possibilities are:
#** {{C:\Users\<username>\AppData\Roaming\Aduna\repositories}} (Windows 7 when running Tomcat as a user)
#** {{C:\Documents and Settings\LocalService\Application Data\Aduna\OpenRDF Sesame\repositories}} (Windows XP when running Tomcat as a service)
# Reselect the SYSTEM repository and press F5


If this is set to an absolute pathname and moving the repository requires an update of this parameter as well, then you will now need to the value of this parameter (with the new name) as described in the question further up about modifying a repository configuration.

** Set the {{GRAPHDB_LICENSE_FILE}} environment variable to point to the license file. This will be overridden by the following methods.
* *Repository configuration parameter*
** Set {{owlim:owlim-license}} in a Turtle configuration/template file, e.g. when using the Sesame console.
** Set the 'License file' field when using the Sesame workbench (the repackaged version in the GraphDB distribution).
* *System property*
** Use {{\-Dowlim-license=<full_path_to_license>}} for the Java virtual machine that is running GraphDB.
** When deployed using Tomcat, the {{CATALINA_OPTS}} or {{JAVA_OPTS}} environment variables can be set, i.e. {{\-Dowlim-license=<full_path_to_license>}}, which will apply to all GraphDB-SE repositories as it overrides each configured repository's license file setting and the environment variable.
** For linux installations, you can also set JAVA_OPTS in the {{/etc/default/tomcat6}} file.

h5. How do I run GraphDB-SE or an GraphDB-Enterprise worker node on a machine with more CPUs than licensed?

The maximum CPU count is checked during GraphDB initialisation by checking for the number of CPU cores available to the Java Virtual Machine (JVM) in which GraphDB is running. If the number of CPU cores available is greater than specified in the license file, then GraphDB will still run, but it will throttle itself to use the equivalent of the licensed number of CPU cores.

GraphDB can be embedded in a user application or deployed using Tomcat/Sesame. In both cases, the user should restrict the number of CPUs available to the JVM in which GraphDB is running. The method to do this depends upon the operating system:
{{C:\WINDOWS\system32\cmd.exe /c start /AFFINITY 5 java}} {{{_}rest_of_command_line{_}}} |

When deploying with Tomcat/Sesame, the easiest method is to edit the startup script(s) for tomcat using the above modifications. The scripts can be found in a variety of locations depending on the operating system, distribution, and installation method. Some command locations are:
* {{/usr/share/tomcat6/bin/}}
* {{/etc/init.d/tomcat6}}

MacOS does not provide an easy means to set the processor affinity. The most straightforward method to limit CPU usage is to create a virtual machine (VM) (using VirtualBox for example) and set the number of processors for this VM to the number of licensed CPU cores. A free linux distribution can then be installed in the VM and Sesame/GraphDB/Tomcat set up as necessary. Alternatively, just use GraphDB as normal and rely on the internal throttling to manage CPU utilisation.


h1. Problems