Increasing the write throughput


#1

I have an aerospike setup in which data is persisted on HDD along with in memory. My java client is a multithreaded application which tries to populate aerospike and i am observing frequent “Device Overload” exceptions. Currently in the namespace configuration i have specified only 1 file location but i was wondering if providing multiple file location mounted on different disk will help me increase the throughput and reduce this exception? I see from the docs that it is possible to provide multiple file locations but its behaviour is not mentioned whether aerospike server will try to write to these files in round robin fashion or sequentially?


AEROSPIKE_ERR_RECORD_NOT_FOUND just after INSERT
#2

This indicates that the underlying storage layer cannot keep up with the write load and our write queue for that device has filled.

Ideally we would use a RAW device instead of going through the file system. Even for HDD backed namespaces you may specify device /dev/sd? rather than files. If you must go through a filesystem, mounting the device with noatime will help performance.

Having multiple files/devices typically shows IO improvement, especially if on different physical devices.

There are a few bits in the RIPEMD 160 digest used to determine which drive to write to.


#3

Can i use the the same RAW device for multiple namespaces?? Will it cause any conflict?? I decided to use file instead of device because that gave me the freedom to cleanup the namespace at one shot if ever needed by deleting that file,can i do something similar if i use the RAW device?


#4

You cannot share the same device with multiple namespaces, Aerospike will detect the problem and fail to start. You can, however, partition the device and use the partitions to allocate portions of the device to different namespaces (of course not the same portion to multiple namespaces).

Please read through our Namespace Configuration documentation.

You will have a performance penalty for going through the filesystem. As I said before, some of this penalty can be recovered by mounting the underlying device with noatime.

For SSDs, you could use blkdiscard to zeroize a raw device.

Example:

sudo blkdiscard /dev/sdc

If your system doesn’t have blkdiscard or you aren’t using SSDs, you could use dd instead which will be much slower. To zeroize with dd see the following example:

sudo dd if=/dev/zero of=/dev/sdc bs=1M