-
Notifications
You must be signed in to change notification settings - Fork 583
Legacy FLASH Storage
DRAM is significantly more expensive per GB than non volatile memory such as FLASH. When enabled KeyDB can store less frequently accessed data in non volatile storage instead of RAM. KeyDB will actively page data in and out of non volatile storage as necessary. Of course you can also use plain spinning disks, but it is not recommended as performance will be poor. KeyDB expects the underlying device to have good random I/O performance.
FLASH storage is only used for temporary data and behaves similar to RAM. Persistence is still accomplished through the normal mechanisms. Memory used by KeyDB will show up as "buff/cache" when looking at memory with the 'free' command. KeyDB relies on the kernel's paging policy for decisions on what to put on disk.
KeyDB relies on file system snapshots to keep data backups quick and efficient. As such you must use a filesystem with snapshot support such as BTRFS or ZFS. Additionally because this feature has a slight overhead you must enable it at compile time. Docker images with this feature compiled in are available. See the compiling section for more information on how to build from source with this feature enabled.
A new configuration option is added which will enable this feature and determine where the scratch file goes. This must be a path to a directory on a filesystem with snapshotting enabled. KeyDB will make a temporary file in this directory which will automatically be deleted when the program is closed.
scratch-file-path /path
Note: As a consequence of how the automatic deletion works you may not see the file in this directory with 'ls'. The 'df' command and 'lsof' command can instead be used to get better information on the disk usage of this file.
When compiling the malloc must be set to 'memkind' using the following command:
make MALLOC=memkind