Home Getting Started Installation & Setup Development & Integration Deployment & Operations Data Management Technical Support Platform Updates

DocsDeployment & OperationsOperating Stardogserver configuration

Server Configuration

This page discusses configuring the Stardog server. Configuring a Stardog database is discussed in detail in the Database Configuration section.

<details open markdown="block"> <summary> Page Contents </summary> 1. TOC </details>

`stardog.properties`

The main configuration file for Stardog is the stardog.properties file, which is a Java properties file. This file contains configuration properties to configure Stardog's global behavior. The stardog.properties file should be placed into the $STARDOG_HOME directory to take effect.

To specify another location for the stardog.properties file, you can set the STARDOG_PROPERTIES environment variable.

Example

An example stardog.properties file is provided in our Stardog examples Github repository.

Updatable Properties

For most server properties to take effect in a running Stardog Server, it is necessary to restart it. However, certain properties (e.g. some of the LDAP properties) are updatable and can be mutated without a restart using the property set admin command, which updates a property (on all Stardog servers in a cluster) and saves the change to the stardog.properties file. Use the property get command to see a list of all set server properties (updatable and otherwise).

Configuration Options

The properties described in this section control the global behavior of the Stardog Server.

You'll observe each server property has a field "Overridable". Overridable, in this context, means you can set this option at the database level, overriding the value set for the server. This isn't relevant for most properties, but can be useful for setting query-related properties, for example. See the Database Configuration section for details on setting and configuring database options.

Query Answering

Properties to configure queries at the server level:

`query.all.graphs`

<dl> <dt>Default</dt> <dd><code>false</code></dd> <dt>Description</dt> <dd>If a SPARQL query does not use <code>FROM</code> or <code>FROM NAMED</code> keywords, this option will define what data it is evaluated against; if <code>true</code>, it will run over the default graph and the union of all named graphs; if <code>false</code> (the default), it will run only over the default graph.</dd> <dt>Overridable</dt> <dd>true</dd> </dl>

`query.timeout`

<dl> <dt>Default</dt> <dd><code>5m</code></dd> <dt>Description</dt> <dd>Sets the upper bound for query execution time. This value is inherited by all databases unless explicitly overridden by a database-specific timeout value in <a href="../database-administration/database-configuration#querytimeout">database options</a>. The following unit suffixes are available: "ms" for milliseconds, "s" for seconds, "m" for minutes, and "h" for hours.</dd> <dt>Overridable</dt> <dd>true</dd> </dl>

`query.update.timeout`

<dl> <dt>Default</dt> <dd><code>10h</code></dd> <dt>Description</dt> <dd>Sets the upper bound for SPARQL Update query execution time. This value is inherited by all databases unless explicitly overridden by a database-specific timeout value in <a href="../database-administration/database-configuration#queryupdatetimeout">database options</a>. The following unit suffixes are available: "ms" for milliseconds, "s" for seconds, "m" for minutes, and "h" for hours.</dd> <dt>Overridable</dt> <dd>true</dd> </dl>

`query.timeout.override.enabled`

<dl> <dt>Default</dt> <dd><code>true</code></dd> <dt>Description</dt> <dd>When enabled, users are able to override the default timeout value. When disabled, queries must respect the value set in <a href="./server-configuration#querytimeout"><code>query.timeout</code></a>.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

Connection Configuration

`database.connection.timeout`

<dl> <dt>Default</dt> <dd><code>10m</code></dd> <dt>Description</dt> <dd>The amount of time a connection to the database can be open, but inactive, before being automatically closed to reclaim the resources. The timeout values specified in the property file should be a positive integer followed by either letter 'h' (for hours), letter 'm' (for minutes), letter 's' (for seconds), or letters 'ms' (for milliseconds). Example intervals: <code>1h</code> for 1 hour, <code>5m</code> for 5 minutes, <code>90s</code> for 90 seconds, <code>500ms</code> for 500 milliseconds. NOTE: setting a short timeout can have adverse results, especially if updates are being performed without commit changes to the server. This can close the connection prematurely while using it.</dd> <dt>Overridable</dt> <dd>true</dd> </dl>

Limits

Properties to configure limits on databases and triples at the server level. These limits allow administrators to set caps that are lower than (but cannot exceed) the limits defined by the Stardog license. If not set, the license limits apply.

`database.count.limit`

<dl> <dt>Default</dt> <dd><code></code></dd> <dt>Description</dt> <dd>User-defined limit for the maximum number of databases that can be created on the server. System-created databases (e.g., <code>catalog</code> and <code>querylog</code>) are excluded from this count. This limit must not exceed the license limit. If not set, the license limit applies.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`database.triple.limit`

<dl> <dt>Default</dt> <dd><code></code></dd> <dt>Description</dt> <dd>User-defined limit for the maximum number of triples in a single database. This limit applies to all databases including system databases (e.g., <code>catalog</code> and <code>querylog</code>). This limit must not exceed the license limit. If not set, the license limit applies. Supports human-readable format (e.g., <code>10M</code>, <code>1.5B</code>, <code>500K</code>).</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`server.triple.limit`

<dl> <dt>Default</dt> <dd><code></code></dd> <dt>Description</dt> <dd>User-defined limit for the total number of triples across all databases on the server. Triples in system databases (e.g., <code>catalog</code> and <code>querylog</code>) count toward this limit. This limit must not exceed the license limit. If not set, the license limit applies. Supports human-readable format (e.g., <code>100M</code>, <code>5B</code>, <code>10K</code>).</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

Backups

Server properties for backing up the Stardog server and databases.

`backup.dir`

<dl> <dt>Default</dt> <dd><code>$STARDOG_HOME/.backup</code></dd> <dt>Description</dt> <dd>The top level directory which is to be used by Stardog for storing backups. By default, this is the <code>.backup</code> directory in your <code>$STARDOG_HOME</code>, but you can use this property to specify a different location for backups. Within this directory, backups are stored by database, and for each database, in date-versioned directories.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`backup.location`

<dl> <dt>Default</dt> <dd><code></code></dd> <dt>Description</dt> <dd>This property can be set if you need to specify a backup location outside of <code>$STARDOG_HOME</code> (e.g. a network mount). A default S3 or GCP backup location can also be specified here. See the sections <a href="../database-administration/backup-and-restore#backup-to-s3">Backup to S3</a> and <a href="../database-administration/backup-and-restore#backup-to-google-cloud-platform-gcp">Backup to GCP</a> for more info.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`backup.keep.last.number.backups`

<dl> <dt>Default</dt> <dd><code>4</code></dd> <dt>Description</dt> <dd>Controls how many server backups will be retained by Stardog. See the <a href="./backup-and-restore">Server Backup & Restore</a> section for more details.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`backup.autorestore.dbnames`

<dl> <dt>Default</dt> <dd><code></code></dd> <dt>Description</dt> <dd>A regular expression that matches the names of the databases to automatically restore on startup, eg: <code>.*</code> for every database. See <a href="../database-administration/backup-and-restore#automatic-restore">Automatic Restore</a> for more information.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`backup.autorestore.onfailure`

<dl> <dt>Default</dt> <dd><code>false</code></dd> <dt>Description</dt> <dd>A boolean value that determines if all databases which failed to load should be automatically restored from a backup location. See <a href="../database-administration/backup-and-restore#automatic-restore">Automatic Restore</a> for more information.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

Memory

Server properties to configure memory in Stardog.

`memory.management`

<dl> <dt>Default</dt> <dd><code>NATIVE</code></dd> <dt>Description</dt> <dd>To disable custom memory management and have Stardog run all queries on heap, you can set this property to <code>JVM</code>. Please consult the <a href="./memory-management">memory management</a> section of the docs to learn more about how Stardog manages memory and to see if modifying this property is right for you.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`memory.mode`

<dl> <dt>Default</dt> <dd><code>default</code></dd> <dt>Description</dt> <dd>Stardog defines three standard memory consumption modes to allow users to configure how memory should be distributed based on the usage scenario - <code>read_optimized</code>, <code>write_optimized</code>, <code>bulk_load</code>. Please consult the <a href="./memory-management#memory-configuration">memory management</a> section of the docs to learn more about these options.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`memory.managed.block.size`

<dl> <dt>Default</dt> <dd><code>32K</code></dd> <dt>Description</dt> <dd>Size of blocks allocated by the memory management subsystem. Smaller blocks may improve memory utilization but increase overhead.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`memory.managed.allocate.immediately`

<dl> <dt>Default</dt> <dd><code>true</code></dd> <dt>Description</dt> <dd>Immediately allocate the maximum number of memory blocks on server start.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`spilling.dir`

<dl> <dt>Default</dt> <dd><code>$STARDOG_HOME/.spilling</code></dd> <dt>Description</dt> <dd>When Stardog cannot handle an operation (e.g. a query) in memory, it spills data to disk. This property determines the directory these operations will spill data to. By default, data will be spilled to the <code>.spilling</code> directory inside <code>$STARDOG_HOME</code>. It may make sense to set this to another disk to minimize disk contention. </dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`spilling.max.file.length`

<dl> <dt>Default</dt> <dd><code>10G</code></dd> <dt>Description</dt> <dd>When Stardog cannot handle an operation in memory, it spills data to disk. This property controls the maximum size of a single file Stardog will spill data to. A query can spill to multiple files and each are bound by the value set here. NOTE: this will only take effect if the server property, <code><a href="#memorymanagement">memory.management</a></code>, is also enabled, which Stardog does by default.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`query.memory.limit.hard`

<dl> <dt>Default</dt> <dd><code>9223372036854775807B</code></dd> <dt>Description</dt> <dd>Configuration option for determining the memory limit used by query. Value should be provided in bytes as seen in the default value. This value overrides lower database configurations.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`query.memory.exceeds.strategy.hard`

<dl> <dt>Default</dt> <dd><code>SPILL_TO_DISK</code></dd> <dt>Description</dt> <dd>Configuration option for determining strategy for the query behaviour once query memory limit reached. Specifying FINISH_QUERY_EXECUTION will override database configurations. Query memory limit is determined by the server configuration option <code><a href="#querymemorylimit">query.memory.limit</a></code>.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

Geospatial

Server properties to modify Stardog's geospatial support.

`spatial.use.jts`

<dl> <dt>Default</dt> <dd><code>false</code></dd> <dt>Description</dt> <dd>Enable support for JTS in the <a href="../../query-stardog/geospatial-queries#enhanced-polygons">geospatial module</a>.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

Cluster

Server properties for Stardog Cluster.

`pack.enabled`

<dl> <dt>Default</dt> <dd><code>false</code></dd> <dt>Description</dt> <dd>Flag to enable the cluster. Without this flag set, the rest of the cluster properties have no effect.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`pack.node.address`

<dl> <dt>Default</dt> <dd><code><a href="https://docs.oracle.com/javase/8/docs/api/java/net/InetAddress.html">InetAddress.getLocalhost().getAddress()</a></code></dd> <dt>Description</dt> <dd>The local address of the node. The default value of this property is <code><a href="https://docs.oracle.com/javase/8/docs/api/java/net/InetAddress.html">InetAddress.getLocalhost().getAddress()</a></code>, which should work for many deployments. However, if you’re using an atypical network topology and the default value is not correct, you can provide a value for this property. If provided, it should be unique for each Stardog node.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`pack.zookeeper.address`

<dl> <dt>Default</dt> <dd><code></code></dd> <dt>Description</dt> <dd>A ZooKeeper connection string where cluster stores its state.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`pack.zookeeper.auth`

<dl> <dt>Default</dt> <dd><code>admin:admin</code></dd> <dt>Description</dt> <dd>When starting Stardog instances for the cluster, unlike single server mode, you need to provide the credentials of a superuser. The superuser will be used for securing the data stored in ZooKeeper and for intra-cluster communication. Each node should be started with the same superuser credentials. By default, Stardog comes with a superuser <code>admin</code> that has password "admin" (these are the default credentials used by the <code><a href="../../stardog-admin-cli-reference/server/server-start">server start</a></code> CLI command). For a secure installation of Stardog cluster, you should change these credentials by specifying this property and restarting the cluster with new credentials.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`pack.connection.timeout`

<dl> <dt>Default</dt> <dd>The default value is the default connection timeout for ZooKeeper.</dd> <dt>Description</dt> <dd>Specifies the max time that Stardog waits to establish a connection to ZooKeeper. See <a href="../../cluster/installation-and-setup/#connectionsession-timeouts">Connection/Session Timeouts</a> for more information.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`pack.session.timeout`

<dl> <dt>Default</dt> <dd>The default value is the default session timeout for ZooKeeper.</dd> <dt>Description</dt> <dd>Specifies the max time that Stardog nodes wait to establish a session with the Zookeeper cluster. See <a href="../../cluster/installation-and-setup/#connectionsession-timeouts">Connection/Session Timeouts</a> for more information.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

Security

Properties used to configure Security in Stardog:

`password.length.min`

<dl> <dt>Default</dt> <dd><code>4</code></dd> <dt>Description</dt> <dd>Sets the password policy for the minimum length of user passwords.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`password.length.max`

<dl> <dt>Default</dt> <dd><code>1024</code></dd> <dt>Description</dt> <dd>Sets the password policy for the maximum length of user passwords.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`password.regex`

<dl> <dt>Default</dt> <dd><code>[\w@#$%!&]+</code></dd> <dt>Description</dt> <dd>Sets the password policy of accepted chars in user passwords, via a Java regular expression.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`password.store.sha1`

<dl> <dt>Default</dt> <dd><code>true</code></dd> <dt>Description</dt> <dd>Sets whether to store SHA1-hashed credentials, required for MySQL Native Authentication</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`security.named.graphs`

<dl> <dt>Default</dt> <dd><code>false</code></dd> <dt>Description</dt> <dd>Sets <a href="../security/named-graph-security">named graph security</a> globally.</dd> <dt>Overridable</dt> <dd>true</dd> </dl>

`security.disable.password`

<dl> <dt>Default</dt> <dd><code>false</code></dd> <dt>Description</dt> <dd>Sets whether username/password authentication is disabled. Default value changes to `true` in conjunction with Kerberos.</dd> <dt>Overridable</dt> <dd>true</dd> </dl>

SSL

Properties used to configure Stardog to use SSL:

`javax.net.ssl.keyStorePassword`

<dl> <dt>Default</dt> <dd><code></code></dd> <dt>Description</dt> <dd>The password for the keystore.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`javax.net.ssl.keyStore`

<dl> <dt>Default</dt> <dd><code></code></dd> <dt>Description</dt> <dd>If this is not specified, <code>$STARDOG_home/keystore</code> is checked. After that, the standard JVM locations within <code>$JAVA_HOME</code> are checked. Example: <code>/path/to/the/keystore</code></dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`javax.net.ssl.keyStoreType`

<dl> <dt>Default</dt> <dd><code>jks</code></dd> <dt>Description</dt> <dd>If the keystore is of a different type than the default (<code>jks</code>), you can specify its type. Example: <code>pkcs12</code></dd> <dt>Overridable</dt> <dd>false</dd> </dl>

LDAP

LDAP and the server properties required for LDAP configuration are described at length in its dedicated chapter.

Kerberos

Kerberos and the server properties required for Kerberos configuration are described at length in its dedicated chapter.

Logging

This section contains configuration properties for logging in Stardog. See the section on Server Logging for further information on configuring logging.

Access Logging

The server properties used for Access Logging are listed below:

`logging.access.enabled`

<dl> <dt>Default</dt> <dd><code>false</code></dd> <dt>Description</dt> <dd>Access log is disabled by default and should be enabled explicitly by setting this to <code>true</code>.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`logging.access.file`

<dl> <dt>Default</dt> <dd><code>${STARDOG_HOME}/access.log</code></dd> <dt>Description</dt> <dd>File name for the access log. By default, the access log is saved as a file named <code>access.log</code> inside the <code>${STARDOG_HOME}</code> directory. Optionally, an absolute path can be provided to save the file in a different directory.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`logging.access.rotation.type`

<dl> <dt>Default</dt> <dd><code></code></dd> <dt>Description</dt> <dd>It is possible to define a file rotation strategy so that access log entries will be split into multiple files. One possibility is to define a limit on file size and start a new file when the size limit is reached. Specify <code>size</code> as the value for this option. Alternately, log files can be rotated at fixed time intervals by specifying a value of <code>time</code>.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`logging.access.rotation.limit`

<dl> <dt>Default</dt> <dd><code></code></dd> <dt>Description</dt> <dd>If you've set <code>logging.access.rotation.type=size</code>, you can specify the size limit in bytes to determine the rotation frequency of the access log. Example: <code>1000000</code>. The file that exceeds the limit will be renamed with a unique suffix, and all the subsequent entries will be added to the newly created file.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`logging.access.rotation.interval`

<dl> <dt>Default</dt> <dd><code></code></dd> <dt>Description</dt> <dd>If you've set <code>logging.access.rotation.type=time</code>, you can specify the log to be rotated at fixed time intervals. The interval value should be a positive integer followed by either letter 'd' (for days) or letter 'h' (for hours). Examples intervals are <code>7d</code> for weekly logs, <code>1d</code> for daily logs, <code>12h</code> for two log files per day, and <code>1h</code> for hourly logs. The file that exceeds the interval will be renamed with a unique suffix, and all the subsequent entries will be added to the newly created file.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`logging.access.rotation.compress`

<dl> <dt>Default</dt> <dd><code>false</code></dd> <dt>Description</dt> <dd>When rotation is enabled, setting this options to <code>true</code> will cause rotated log files to be compressed with gzip.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`logging.access.rotation.file.count`

<dl> <dt>Default</dt> <dd><code>-1</code></dd> <dt>Description</dt> <dd>The maximum number of rotated files to keep. When the number of rotated files exceeds this limit, the oldest rotated file will be deleted. Setting this option to <code>-1</code> means the limit is undefined, and all rotated files will be kept indefinitely. If the option is set to <code>0</code>, then no rotated files will be kept. Once the log file reaches the rotation limit, it will be deleted, and a fresh log file will be created.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

Audit Logging

The server properties used for Audit Logging are listed below:

`logging.audit.enabled`

<dl> <dt>Default</dt> <dd><code>false</code></dd> <dt>Description</dt> <dd>Audit log is disabled by default and should be enabled explicitly by setting this to <code>true</code>.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`logging.audit.file`

<dl> <dt>Default</dt> <dd><code>${STARDOG_HOME}/audit.log</code></dd> <dt>Description</dt> <dd>File name for the audit log. By default, audit log is saved as a file named <code>audit.log</code> inside the <code>${STARDOG_HOME}</code> directory. Optionally an absolute path can be provided to save the file in a different directory.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`logging.audit.rotation.type`

<dl> <dt>Default</dt> <dd><code></code></dd> <dt>Description</dt> <dd>It is possible to define a file rotation strategy so that audit log entries will be split into multiple files. One possibility is to define a limit on file size and start a new file when the size limit is reached. Specify <code>size</code> as the value for this option. Alternately, log files can be rotated at fixed time intervals by specifying a value of <code>time</code>.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`logging.audit.rotation.limit`

<dl> <dt>Default</dt> <dd><code></code></dd> <dt>Description</dt> <dd>If you've set <code>logging.audit.rotation.type=size</code>, you can specify the size limit in bytes to determine the rotation frequency of the audit log. Example: <code>1000000</code>. The file that exceeds the limit will be renamed with a unique suffix, and all the subsequent entries will be added to the newly created file.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`logging.audit.rotation.interval`

<dl> <dt>Default</dt> <dd><code></code></dd> <dt>Description</dt> <dd>If you've set <code>logging.audit.rotation.type=time</code>, you can specify the log to be rotated at fixed time intervals. The interval value should be a positive integer followed by either letter 'd' (for days) or letter 'h' (for hours). Examples intervals are <code>7d</code> for weekly logs, <code>1d</code> for daily logs, <code>12h</code> for two log files per day, and <code>1h</code> for hourly logs. The file that exceeds the interval will be renamed with a unique suffix, and all the subsequent entries will be added to the newly created file.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`logging.audit.rotation.compress`

`logging.audit.rotation.file.count`

Slow Query Logging

The server properties used for Slow Query Logging are listed below:

The Query Log Database provides a more powerful way to track and analyze query performance. It stores query execution information as RDF, making it queryable with SPARQL and easier to analyze than log files.

`logging.slow_query.enabled`

<dl> <dt>Default</dt> <dd><code>false</code></dd> <dt>Description</dt> <dd>Slow query logging is disabled by default and should be enabled explicitly by setting this to <code>true</code>.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`logging.slow_query.file`

<dl> <dt>Default</dt> <dd><code>${STARDOG_HOME}/slow_query.log</code></dd> <dt>Description</dt> <dd>File name for the slow query log. By default, slow query log is saved as a file named <code>slow_query.log</code> inside the <code>${STARDOG_HOME}</code> directory. Optionally an absolute path can be provided to save the file in a different directory.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`logging.slow_query.time`

<dl> <dt>Default</dt> <dd><code>1m</code></dd> <dt>Description</dt> <dd>To define what counts as a "slow" query, set this property to a time duration value (positive integer plus <code>h</code>, <code>m</code>, <code>s</code>, or <code>ms</code> for hours, minutes, seconds, or milliseconds respectively).</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`logging.slow_query.type`

<dl> <dt>Default</dt> <dd><code>text</code></dd> <dt>Description</dt> <dd>Log type. The default type (<code>text</code>) formats slow query events in a human-readable format intended for developers to read. This default format is not suitable for machine-processing. For a machine-processable format, the type can be set to <code>json</code>.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`logging.slow_query.rotation.type`

<dl> <dt>Default</dt> <dd><code></code></dd> <dt>Description</dt> <dd>It is possible to define a file rotation strategy so that slow query log entries will be split into multiple files. One possibility is to define a limit on file size and start a new file when the size limit is reached. Specify <code>size</code> as the value for this option. Alternately, log files can be rotated at fixed time intervals by specifying a value of <code>time</code>.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`logging.slow_query.rotation.limit`

<dl> <dt>Default</dt> <dd><code></code></dd> <dt>Description</dt> <dd>If you've set <code>logging.slow_query.rotation.type=size</code>, you can specify the size limit in bytes to determine the rotation frequency of the slow query log. Example: <code>1000000</code>. The file that exceeds the limit will be renamed with a unique suffix, and all the subsequent entries will be added to the newly created file.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`logging.slow_query.rotation.interval`

<dl> <dt>Default</dt> <dd><code></code></dd> <dt>Description</dt> <dd>If you've set <code>logging.slow_query.rotation.type=time</code>, you can specify the log to be rotated at fixed time intervals. The interval value should be a positive integer followed by either letter 'd' (for days) or letter 'h' (for hours). Examples intervals are <code>7d</code> for weekly logs, <code>1d</code> for daily logs, <code>12h</code> for two log files per day, and <code>1h</code> for hourly logs. The file that exceeds the interval will be renamed with a unique suffix, and all the subsequent entries will be added to the newly created file.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`logging.slow_query.rotation.compress`

`logging.slow_query.rotation.file.count`

Monitoring

Properties used to configure Server Monitoring:

`metrics.reporter`

<dl> <dt>Default</dt> <dd><code></code></dd> <dt>Description</dt> <dd>Enables <a href="./server-monitoring#jmx-monitoring">JMX monitoring</a> by setting this property to a value of <code>jmx</code>.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`metrics.jmx.remote.access`

<dl> <dt>Default</dt> <dd><code>false</code></dd> <dt>Description</dt> <dd>When set to <code>true</code>, Stardog will bind an RMI server for remote access on port <code>5833</code> to connect to the JMX server remotely. To change the port, modify the <code><a href="#metricsjmxport">metrics.jmx.port</a></code> server property.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`metrics.jmx.port`

<dl> <dt>Default</dt> <dd><code>5833</code></dd> <dt>Description</dt> <dd>The port Stardog will expose for a JMX server to connect to <a href="#metricsjmxremoteaccess">remotely</a>.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

Exports

`export.dir`

<dl> <dt>Default</dt> <dd><code>$STARDOG_HOME/.exports</code></dd> <dt>Description</dt> <dd>The top-level directory for storing files which are exported by the server. The default value is <code>.exports</code> in your <code>$STARDOG_HOME</code> directory.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

HTTP Configuration

`http.max.connection`

<dl> <dt>Default</dt> <dd><code>200</code></dd> <dt>Description</dt> <dd> The maximum number of simultaneous http connections.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`http.max.get.query.length`

<dl> <dt>Default</dt> <dd><code>2000</code></dd> <dt>Description</dt> <dd>The length in characters of the longest query that can be sent over HTTP GET to the Stardog server. This is to avoid URL overflow in some web servers. When the query is longer than this threshold, Stardog will automatically switch over to using HTTP POST.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`http.max.request.parameters`

<dl> <dt>Default</dt> <dd><code>2000</code></dd> <dt>Description</dt> <dd>Any value smaller than Java's <code>Integer.MAX_VALUE</code> may be provided. Useful if you have lots of named graphs and are at risk of exceeding the default value.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`cors.allowed.origins`

<dl> <dt>Default</dt> <dd><code></code></dd> <dt>Description</dt> <dd>By default, CORS is enabled on Stardog's HTTP server. (It can be disabled when starting the server via the <a href="../../stardog-admin-cli-reference/server/server-start">CLI</a> by including the <code>--no-cors</code> flag.) In order for any cross-origin requests to be acknowledged, their Origin header value must be included in this list. Example: <code>http://stardog.com, http://example.org</code></dd> <dt>Overridable</dt> <dd>false</dd> </dl>

Optimizer Configuration

`optimizer.join.order.robustness`

<dl> <dt>Default</dt> <dd><code>true</code></dd> <dt>Description</dt> <dd>When enabled, the query plan optimizer will consider alternative join orders in the presence of SPARQL-based services and select a *robust* query plan. See <a href="../../virtual-graphs/optimization#robust-query-planning">this section</a> for more details. The behaviour can also be disabled on a per-query basis using the <a href="../../query-stardog/query-hints#federation-hints"><code>optimizer.join.order.topk</code></a> query hint. </dd> <dt>Overridable</dt> <dd>false</dd> </dl>

System Database Checkpoints

`storage.checkpoint.system.interval.minutes`

<dl> <dt>Default</dt> <dd><code>360</code></dd> <dt>Description</dt> <dd>When non-zero, Stardog automatically creates a checkpoint of the system database every XX minutes. Checkpoints provide a quick backup of the Stardog's internal management data. See <a href="../database-administration/checkpoint"> this section</a> for more details.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`storage.checkpoint.system.intervals.keep`

<dl> <dt>Default</dt> <dd><code>3</code></dd> <dt>Description</dt> <dd>When non-zero, Stardog automatically removes older interval checkpoints, keeping the most recent XX checkpoints.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`storage.checkpoint.system.days.keep`

<dl> <dt>Default</dt> <dd><code>3</code></dd> <dt>Description</dt> <dd>When non-zero, Stardog automatically keeps the last interval checkpoint of each day for the last XX days. Stardog will remove checkpoints older than XX days.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

`storage.checkpoint.system.weeks.keep`

<dl> <dt>Default</dt> <dd><code>2</code></dd> <dt>Description</dt> <dd>When non-zero, Stardog automatically keeps the last interval checkpoint of each week for the last XX weeks. Typically this is the last interval checkpoint on Sunday. Stardog will remove checkpoints older than XX weeks.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

Database Optimize

`storage.overload.optimize.threads`

<dl> <dt>Default</dt> <dd><code>false</code></dd> <dt>Description</dt> <dd>Database optimize is very cpu and disk resource intensive. Stardog's default configuration is to intentionally throttle the optimize operation. The throttling ensures that queries executing simultaneously are not severely impacted. Setting this option to true disables the intentional throttling. An example use is when database optimize is known to execute at night when user queries do not occur.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

Network Connection Keepalive

`stardog.keep.alive.enabled`

<dl> <dt>Default</dt> <dd><code>true</code></dd> <dt>Description</dt> <dd><a href="https://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html">Keepalive is a network feature</a> supplied by the operating system. The feature requires that Stardog request the keepalive support for each network connection from client/user applications. Stardog does this by default since version 10.2. Keepalive is especially helpful to long processing requests, such as database optimize, when those requests cross routers/gateways that exist between the client and Stardog. Setting this option to false disables the feature.</dd> <dt>Overridable</dt> <dd>false</dd> </dl>

Keepalive often needs tuning at the operating system level to address specific network conditions. By default, the operating system only initiates keepalive after 2 hours. Yet network routers might terminate dormant network connections after as little as 4 minutes. Details on how to configure keepalive can be found <a href="https://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html">here.</a> Similar web pages discussing specific installations, such as kubernetes, exist and are easily found via web search engines.