3. Performance tuning

3.1. Daemon

Please refer to the performance section of the daemon documentation for important tips regarding performance tuning of the daemon (see Performance tuning).

3.2. Testing cluster connectivity

The most frequent cause of failure is the improprer configuration of the operating system which prevents quasardb from opening enough sockets.

The qdb_max_conn command line tool available in the tools package will tell you exactly how much connections can be opened to a quasardb cluster.

For example, to test how many connections you can open to a cluster listening on

qdb_max_conn qdb://

If you cannot generate at least 1,000 connections you have a serious operating system configuration. A properly configured quasardb cluster should easily handle tens of thousands of connections.

3.3. Rules of thumb

  • Pageins - If you see a lot of pageins, it means you should allocate more physical memory to the daemon (see Configuration).

  • Physical memory usage - If physical memory usage is too high (the node swaps), you will need to either reduce the memory usage of the daemon, add more memory to the node or add more nodes to the cluster.

  • Disk usage - If the disk is full, the quasardb node will refuse to serve requests resulting in failures and performance drop. The disk may be full for two reasons: * The database takes up too much space: either clean up the database, increase disk space or add more nodes to your cluster. * The log files take too much space: clean up the log and archive them on a different node.

  • CPU usage - If your cpu usage is too high, you will need to add more nodes to your cluster.

  • Network I/O - If your network bandwidth is saturated on one or several nodes, you will need to add more nodes to your cluster.

3.4. Recommendations

  • The more RAM the better. For small clusters, it’s less expensive to add RAM to every node than to add new nodes.

  • Homogenous node configurations make it easier to diagnose performance issues.

  • A quasardb cluster can be very network intensive. Make sure you have the network infrastructure the handle the load.

  • Don’t be afraid to add nodes. It’s simple and safe.

3.5. File system

QuasarDB internally uses blocks of 64 kib, it’s greatly recommended to configure the filesystem on which data will be stored to use blocks of 64 kib.

3.6. OS X Recommendations

Run ulimit -n as a regular user. If the value is less than 65000, you should update the values. For example, to set it to 65535:

sudo launchctl limit maxfiles 65535 65535

3.7. Linux Recommendations

  1. Disable system swappiness in /etc/sysctl.conf (requires reboot):


    For kernel version 3.5 and over, as well as Red Hat kernel version 2.6.32-303:

  2. (Alternatively) You can use sysctl to disable system swappiness without rebooting:

    sysctl -w vm.swappiness=0

    For kernel version 3.5 and over, as well as Red Hat kernel version 2.6.32-303:

    sysctl -w vm.swappiness=1
  3. Disable Transparent Huge Pages by adding the following to /etc/rc.local:

    if test -f /sys/kernel/mm/transparent_hugepage/enabled; then
        echo never > /sys/kernel/mm/transparent_hugepage/enabled
    if test -f /sys/kernel/mm/transparent_hugepage/defrag; then
        echo never > /sys/kernel/mm/transparent_hugepage/defrag

    You may need as well to make /etc/rc.local executable:

    chmod +x /etc/rc.local
  4. If using a Gigabit Ethernet connection, edit /etc/sysctl.conf and set the following values:

  5. (Optional) If running Linux 3.11 or later, you can benefit from busy polling:

  6. Run ulimit -n as a regular user. If the value is less than 65000, add the following line to /etc/security/limits.conf:

    qdb    soft    nofile    65536
    qdb    hard    nofile    65536
  7. We recommend storing quasardb on a dedicated EXT4 partition with the following parameters:

    • delalloc: Delayed allocation. This is normally the default.

    • data=ordered: Data is written before metadata is updated, preventing inconsistencies. This is normally the default.

    • discard: Enables Trim for SSD drives. Use only for SSD. Ensure the driver of your SSD supports this correctly. This is not enabled by default.

    The partition should be mounted with the following parameters:

    • async: important for SSD lifetime as I/O will be asynchronous.

    • noatime: quasardb doesn’t need access time information

    It is paramount to check that partition alignment is ideal for the drive you are using. Modern partition tools do that automatically but improper alignment can destroy performances.