System Requirements

This page discusses the requirements for running Stardog.

Java

Stardog 9+ is tested on Java version 11, and requires sun.misc.Unsafe. Note that Stardog does not run on any other versions of Java.

To check your version of Java, run the following command from the CLI:

$ java -version

Java 11 can be downloaded from Oracle, which requires creating an account. Alternatively you can use an OpenJDK implementation from Adoptium or Microsoft.

Verified Operating Systems

Stardog is verified to run on:

• Ubuntu 22.04
• Debian 12
• Recent versions of OSX (not recommended for production)

Disk Storage

Stardog runs best on local / block storage devices. Network based disk storage is not recommended, including NFS, SMB, and EFS based storage systems.

If you must use network based disk, please set the following property within stardog.properties file in your $STARDOG_HOME directory:

storage.envoptions.use_mmap_writes = false

Open Files Setting (Linux only)

Linux installations need to verify that the user executing Stardog, often stardog, is configured to allow at least 100,000 open files. This limit impacts both the number of active files and number of active network connections. The configuration setting is within /etc/security/limits.conf. An example setting for user stardog is:

stardog	soft	nofile	100000
stardog	hard	nofile	100000

An alternative is to create a new file within /etc/security/limits.d. An example file would be /etc/security/limits.d/90-stardog.conf that contains the same two lines above. Change stardog to match the user executing the Stardog service (if needed).

This configuration setting is not dynamic. The user must first log out and restart the Stardog service.

For more information on file limits, run man limits.conf from the Linux command line.

vm.swappinness Setting (Linux only)

Linux platforms might have a swap partition, a.k.a. swap memory. This is typical for physical servers. A swap partition is unlikely for containers and AWS instances, but possible. vm.swappiness is the Linux parameter for managing how the linux kernel utilizes the swap memory. The default value is 60, which is modelled for a laptop, not a production server. A Stardog server performs much better when set to zero or one.

It is possible to configure vm.swappiness either at boot-time or at run-time.

Server boot-time configuration

sudo -s
echo "vm.swappiness=0" >> /etc/sysctl.conf

Now reboot the server.

Docker boot-time configuration

If your Docker container happens to have a swap partition, add the following to your “docker run” command:

docker run <existing options> --memory-swappiness=0 <container name>

Server run-time configuration

sudo sysctl -w vm.swappiness=0

or

sudo -s
echo "0" >/proc/sys/vm/swappiness

CAP_SYS_NICE Setting (Linux only)

Stardog processes user query jobs with higher priority than background database grooming jobs. However some background grooming jobs need to have greater priority than other grooming jobs. By default, Linux does not allow the changing of a grooming job’s priority up and down. Once background priority is “down”, there is no default way to make some background jobs “less down”. Fortunately, Linux does provide a way to change from the default.

The Linux kernel has a mechanism for enabling select applications to change priorities both up and down (again, the default is only changing priority down). This mechanism is known as the SYS_NICE capability, a.k.a. cap_sys_nice.

Physical Linux server and Docker containers allow setting the SYS_NICE capability at boot-time.

Server boot-time configuration

sudo setcap 'cap_sys_nice=eip' $(readlink -f $(which java))

verify with

sudo getcap $JAVA_HOME/bin/java

Now reboot the server.

The getcap command should return something similar to: “/usr/lib/jvm/jdk-11.0.27-oracle-x64/bin/java cap_sys_nice=eip”

Note the ending “cap_sys_nice=eip”.

Docker boot-time configuration

Add the following to your “docker run” command:

docker run <existing options> --cap-add SYS_NICE <container name>

Enabling KeepAlive (Linux only)

Some Stardog processes and user queries may take many minutes to execute. Some computer data centers have routers and/or gateways that disconnect network connections that are dormant for too long (example Azure has a 4 minute limit). There exists an industry standard for letting the data center infrastructure know that a network connection should be maintained even though it appears dormant. That standard is called keepalive.

Both the Stardog application and the server or container running Stardog must contribute to keepalive. Stardog always activates keepalive since version 10.2. However the Linux defaults do not activate keepalive for 2 hours (7200 seconds. And 2 hours is often too late. The recommendation is to start keepalive at 2 minutes, a.k.a. 120 seconds.

An official discussion of the server/docker keepalive settings are found here: TCP Keepalive HOWTO

The most important setting is tcp_keepalive_time. This is the value that defaults to 2 hours and needs to be 120 seconds. The other two keepalive values are fine, but could be tuned.

Server boot-time configuration

sudo -s
echo "net.ipv4.tcp_keepalive_time=120" >> /etc/sysctl.conf
echo "net.ipv4.tcp_keepalive_intvl=60" >> /etc/sysctl.conf
echo "net.ipv4.tcp_keepalive_probes=20" >> /etc/sysctl.conf

Now reboot the server.

Docker boot-time configuration

Add the following to your “docker run” command for just tcp_keepalive_time:

docker run <existing options> --sysctl net.ipv4.tcp_keepalive_time=120 <container name>

or all three values

docker run <existing options> --sysctl net.ipv4.tcp_keepalive_time=120
--sysctl net.ipv4.tcp_keepalive_intvl=60 --sysctl net.ipv4.tcp_keepalive_probes=20<container name>

Server run-time configuration

Examples only show the critical value. The other two can be set similarly.

sudo sysctl -w net.ipv4.tcp_keepalive_time=120

or

sudo -s
echo "120" >/proc/sys/net/ipv4/tcp_keepalive_time

---