ownCloud Server Tuning
- Using Cron to Perform Background Jobs
- Enable Memory Caching
- Use Redis-based Transactional File Locking
- Redis Tuning
- Database Tuning
- SSL / Encryption App
- Webserver Tuning
Using Cron to Perform Background Jobs
See Background Jobs for a description and the benefits.
Enable Memory Caching
Caching improves performance by storing data, code, and other objects in memory. Memory cache configuration for ownCloud is no longer automatically available from ownCloud 8.1 but must be installed and configured separately. ownCloud supports Redis, APCu, and Memcached as memory caching backends. See Memory Caching, for further details.
Use Redis-based Transactional File Locking
File locking is enabled by default, using the database locking backend. However, this places a significant load on your database. See the section Transactional File Locking for how to configure ownCloud to use Redis-based Transactional File Locking.
Redis tuning improves both file locking (if used) and memory caching (when using Redis). Here is a brief guide for tuning Redis to improve the performance of your ownCloud installation, when working with sizeable instances.
If you raised the TCP-backlog setting, the following warning appears in the Redis logs:
WARNING: The TCP backlog setting of 20480 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of..
If so, please consider that newer versions of Redis have their own
TCP-backlog value set to
511, and that you have to increase if you
have many connections. In high requests-per-second environments, you
need a significant backlog to avoid slow clients connection issues.
The Linux kernel will silently truncate the TCP-backlog setting to the value of
To fix this warning, set the value of
/etc/rc.local, so that it persists upon reboot, by running the following command.
sudo echo sysctl -w net.core.somaxconn=65535 >> /etc/rc.local
After the next reboot, 65535 connections will be allowed, instead of the default value.
Transparent Huge Pages (THP)
If you are experiencing latency problems with Redis, the following warning may appear in your Redis logs:
WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This creates both latency and memory usage issues with Redis.
If so, unfortunately, when a Linux kernel has Transparent Huge Pages enabled, Redis incurs a significant latency penalty after the fork call is used, to persist information to disk. Transparent Huge Pages are the cause of the following issue:
A fork call is made, resulting in two processes with shared huge pages being created.
In a busy instance, a few event loops cause commands to target a few thousand pages, causing the copy-on-write of almost the entire process memory.
Big latency and memory usage result.
As a result, make sure to disable Transparent Huge Pages using the following command:
echo never > /sys/kernel/mm/transparent_hugepage/enabled
Redis Latency Problems
If you are having issues with Redis latency, please refer to the official Redis guide on how to handle them.
Using MariaDB/MySQL Instead of SQLite
MySQL or MariaDB are preferred because of the performance limitations of SQLite with highly concurrent applications, like ownCloud.
See the section Linux Database Configuration for how to configure ownCloud for MySQL or MariaDB. If your installation is already running on SQLite then it is possible to convert to MySQL or MariaDB using the steps provided in database conversion.
A comprehensive guide to tuning MySQL and MariaDB is outside the scope of the ownCloud documentation. However, here are three links that can help you find further information:
A comprehensive guide to tuning PostgreSQL is outside the scope of the ownCloud documentation. However, here are three links that can help you find further information:
SSL / Encryption App
SSL (HTTPS) and file encryption/decryption can be offloaded to a processor’s AES-NI extension. This can both speed up these operations while lowering processing overhead. This requires a processor with the AES-NI instruction set.
Here are some examples how to check if your CPU / environment supports the AES-NI extension:
For each CPU core present:
grep flags /proc/cpuinfoor as a summary for all cores:
grep -m 1 ^flags /proc/cpuinfoIf the result contains any
aes, the extension is present.
Search e.g. on the Intel web if the processor used supports the extension Intel Processor Feature Filter. You may set a filter by
"AES New Instructions"to get a reduced result set.
For versions of openssl >= 1.0.1, AES-NI does not work via an engine and will not show up in the
openssl enginecommand. It is active by default on the supported hardware. You can check the openssl version via
openssl version -a
If your processor supports AES-NI but it does not show up e.g. via grep or coreinfo, it is maybe disabled in the BIOS.
If your environment runs virtualized, check the virtualization vendor for support.
Enable HTTP/2 Support
If you want to improve the speed of an ownCloud installation, while at the same time increasing its security, you can enable HTTP/2 support for Apache. Please be aware that most browsers require HTTP/2 to be used with SSL enabled.
An Apache process uses around 12MB of RAM. Apache should be configured so that the maximum number of HTTPD processes times 12MB is lower than the amount of RAM. Otherwise the system begins to swap and the performance goes down.
The KeepAlive directive enables persistent HTTP connections, allowing multiple requests to be sent over the same TCP connection. Enabling it reduces latency by as much as 50%. We recommend to keep the KeepAliveTimeout between 3 and 5. Higher numbers can block the Server with inactive connections. In combination with the periodic checks of the sync client the following settings are recommended:
KeepAlive On KeepAliveTimeout 3 MaxKeepAliveRequests 200