Prev |  | Next

## 23.12. Linux Performance Guide

### 23.12.1. Introduction

The key to achieve good performance on reads and writes is to have lots of RAM since disks are so slow. This guide will focus on achieving good write performance on a Linux kernel based operating system.

If you have not already read the information available in Chapter 23, Configuration & Performance, do that now to get some basic knowledge on memory mapping and store files with Neo4j.

This section will guide you through how to set up a file system benchmark and use it to configure your system in a better way.

### 23.12.2. File system benchmark

#### Setup

Create a large file with random data. The file should fit in RAM so if your machine has 4GB of RAM a 1-2GB file with random data will be enough. After the file has been created we will read the file sequentially a few times to make sure it is cached.

    $ dd if=/dev/urandom of=store bs=1M count=1000
    1000+0 records in
    1000+0 records out
    1048576000 bytes (1.0 GB) copied, 263.53 s, 4.0 MB/s
    $
    $ dd if=store of=/dev/null bs=100M
    10+0 records in
    10+0 records out
    1048576000 bytes (1.0 GB) copied, 38.6809 s, 27.1 MB/s
    $
    $ dd if=store of=/dev/null bs=100M
    10+0 records in
    10+0 records out
    1048576000 bytes (1.0 GB) copied, 1.52365 s, 688 MB/s
    $ dd if=store of=/dev/null bs=100M
    10+0 records in
    10+0 records out
    1048576000 bytes (1.0 GB) copied, 0.776044 s, 1.4 GB/s

If you have a standard hard drive in the machine you may know that it is not capable of transfer speeds as high as 1.4GB/s. What is measured is how fast we can read a file that is cached for us by the operating system.

Next we will use a small utility that simulates the Neo4j kernel behavior to benchmark write speed of the system.

    $ git clone git@github.com:neo4j-contrib/tooling.git
    ...
    $ cd tooling/write-test/
    $ mvn compile
    [INFO] Scanning for projects...
    ...
    $ ./run
    Usage: <large file> <log file> <[record size] [min tx size] [max tx size] [tx count] <[--nosync | --nowritelog | --nowritestore | --noread | --nomemorymap]>>

The utility will be given a store file (large file we just created) and a name of a log file. Then a record size in bytes, min tx size, max tx size and transaction count must be set. When started the utility will map the large store file entirely in memory and read (transaction size) records from it randomly and then write them sequentially to the log file. The log file will then force changes to disk and finally the records will be written back to the store file.

#### Running the benchmark

Lets try to benchmark 100 transactions of size 100-500 with a record size of 33 bytes (same record size used by the relationship store).

    $ ./run store logfile 33 100 500 100
    tx_count[100] records[30759] fdatasyncs[100] read[0.96802425 MB] wrote[1.9360485 MB]
    Time was: 4.973
    20.108585 tx/s, 6185.2 records/s, 20.108585 fdatasyncs/s, 199.32773 kB/s on reads, 398.65546 kB/s on writes

We see that we get about 6185 record updates/s and 20 transactions/s with the current transaction size. We can change the transaction size to be bigger, for example writing 10 transactions of size 1000-5000 records:

    $ ./run store logfile 33 1000 5000 10
    tx_count[10] records[24511] fdatasyncs[10] read[0.77139187 MB] wrote[1.5427837 MB]
    Time was: 0.792
    12.626263 tx/s, 30948.232 records/s, 12.626263 fdatasyncs/s, 997.35516 kB/s on reads, 1994.7103 kB/s on writes

With larger transaction we will do fewer of them per second but record throughput will increase. Lets see if it scales, 10 transactions in under 1s then 100 of them should execute in about 10s:

    $ ./run store logfile 33 1000 5000 100
    tx_count[100] records[308814] fdatasyncs[100] read[9.718763 MB] wrote[19.437527 MB]
    Time was: 65.115
    1.5357445 tx/s, 4742.594 records/s, 1.5357445 fdatasyncs/s, 152.83751 kB/s on reads, 305.67502 kB/s on writes

This is not very linear scaling. We modified a bit more than 10x records in total but the time jumped up almost 100x. Running the benchmark watching vmstat output will reveal that something is not as it should be:

    $ vmstat 3
    procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
     r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
     0  1  47660 298884 136036 2650324    0    0     0 10239 1167 2268  5  7 46 42
     0  1  47660 302728 136044 2646060    0    0     0  7389 1267 2627  6  7 47 40
     0  1  47660 302408 136044 2646024    0    0     0 11707 1861 2016  8  5 48 39
     0  2  47660 302472 136060 2646432    0    0     0 10011 1704 1878  4  7 49 40
     0  1  47660 303420 136068 2645788    0    0     0 13807 1406 1601  4  5 44 47

There are a lot of blocks going out to IO, way more than expected for the write speed we are seeing in the benchmark. Another observation that can be made is that the Linux kernel has spawned a process called "flush-x:x" (run top) that seems to be consuming a lot of resources.

The problem here is that the Linux kernel is trying to be smart and write out dirty pages from the virtual memory. As the benchmark will memory map a 1GB file and do random writes it is likely that this will result in 1/4 of the memory pages available on the system to be marked as dirty. The Neo4j kernel is not sending any system calls to the Linux kernel to write out these pages to disk however the Linux kernel decided to start doing so and it is a very bad decision. The result is that instead of doing sequential like writes down to disk (the logical log file) we are now doing random writes writing regions of the memory mapped file to disk.

It is possible to observe this behavior in more detail by looking at /proc/vmstat "nr_dirty" and "nr_writeback" values. By default the Linux kernel will start writing out pages at a very low ratio of dirty pages (10%).

    $ sync
    $ watch grep -A 1 dirty /proc/vmstat
    ...
    nr_dirty 22
    nr_writeback 0

The "sync" command will write out all data (that needs writing) from memory to disk. The second command will watch the "nr_dirty" and "nr_writeback" count from vmstat. Now start the benchmark again and observe the numbers:

    nr_dirty 124947
    nr_writeback 232

The "nr_dirty" pages will quickly start to rise and after a while the "nr_writeback" will also increase meaning the Linux kernel is scheduling a lot of pages to write out to disk.

#### Fixing the problem

As we have 4GB RAM on the machine and memory map a 1GB file that does not need its content written to disk (until we tell it to do so because of logical log rotation or Neo4j kernel shutdown) it should be possible to do endless random writes to that memory with high throughput. All we have to do is to tell the Linux kernel to stop trying to be smart. Edit the /etc/sysctl.conf (need root access) and add the following lines:

    vm.dirty_background_ratio = 50
    vm.dirty_ratio = 80

Then (as root) execute:

    # sysctl -p

The "vm.dirty_background_ratio" tells at what ratio should the linux kernel start the background task of writing out dirty pages. We increased this from the default 10% to 50% and that should cover the 1GB memory mapped file. The "vm.dirty_ratio" tells at what ratio all IO writes become synchronous, meaning that we can not do IO calls without waiting for the underlying device to complete them (which is something you never want to happen).

Rerun the benchmark:

    $ ./run store logfile 33 1000 5000 100
    tx_count[100] records[265624] fdatasyncs[100] read[8.35952 MB] wrote[16.71904 MB]
    Time was: 6.781
    14.7470875 tx/s, 39171.805 records/s, 14.7470875 fdatasyncs/s, 1262.3726 kB/s on reads, 2524.745 kB/s on writes

Results are now more in line with what can be expected, 10x more records modified results in 10x longer execution time. The vmstat utility will not report any absurd amount of IO blocks going out (it reports the ones caused by the fdatasync to the logical log) and Linux kernel will not spawn a "flush-x:x" background process writing out dirty pages caused by writes to the memory mapped store file.

### 23.12.3. File system tuning for high IO

In order to support the high IO load of small transactions from a database, the underlying file system should be tuned. Symptoms for this are low CPU load with high iowait. In this case, there are a couple of tweaks possible on Linux systems:

- Disable access-time updates: `noatime,nodiratime` flags for disk mount command or in the /etc/fstab for the database disk volume mount.
- Tune the IO scheduler for high disk IO on the database disk.

### 23.12.4. Setting the number of open files

Linux platforms impose an upper limit on the number of concurrent files a user may have open. This number is reported for the current user and session with the command

    user@localhost:~$ ulimit -n
    1024

The usual default of 1024 is often not enough, especially when many indexes are used or a server installation sees too many connections (network sockets count against that limit as well). Users are therefore encouraged to increase that limit to a healthy value of 40000 or more, depending on usage patterns. Setting this value via the `ulimit` command is possible only for the root user and that for that session only. To set the value system wide you have to follow the instructions for your platform.

What follows is the procedure to set the open file descriptor limit to 40k for user neo4j under Ubuntu 10.04 and later. If you opted to run the neo4j service as a different user, change the first field in step 2 accordingly.

1. Become root since all operations that follow require editing protected system files.

       user@localhost:~$ sudo su -
       Password:
       root@localhost:~$

2. Edit `/etc/security/limits.conf` and add these two lines:

       neo4j   soft    nofile  40000
       neo4j   hard    nofile  40000

3. Edit `/etc/pam.d/su` and uncomment or add the following line:

       session    required   pam_limits.so

4. A restart is required for the settings to take effect.

   After the above procedure, the neo4j user will have a limit of 40000 simultaneous open files. If you continue experiencing exceptions on `Too many open files` or `Could not stat() directory` then you may have to raise that limit further.

Copyright © 2014 Neo Technology

Prev | Up | Next
| Home |