Formatting (more)
Former-commit-id: 78b9d303d3146c9a3121fff4e92f2043c0e50518
This commit is contained in:
parent
34e7dcd9a5
commit
9b186a5895
@ -24,15 +24,15 @@ New Configuration Options
|
||||
|
||||
With new features comes new options:
|
||||
|
||||
**server-threads** *N*
|
||||
server-threads N
|
||||
|
||||
The number of threads used to serve requests. This should be related to the number of queues available in your network hardware, *not* the number of cores on your machine. Because KeyDB uses spinlocks to reduce latency; making this too high will reduce performance. We recommend using 4 here. By default this is set to one.
|
||||
|
||||
**scratch-file-path** *path*
|
||||
scratch-file-path /path
|
||||
|
||||
If you would like to use the FLASH backed storage this option configures the directory for KeyDB's temporary files. This feature relies on snapshotting to work so must be used on a BTRFS filesystem. ZFS may also work but is untested. With this feature KeyDB will use RAM as a cache and page to disk as necessary. NOTE: This requires special compilation options, see Building KeyDB below.
|
||||
|
||||
**db-s3-object** *path*
|
||||
db-s3-object /path/to/bucket
|
||||
|
||||
If you would like KeyDB to dump directly to AWS S3 this option specifies the bucket. Using this option with the traditional RDB options will result in KeyDB backing up twice to both locations. This requires the AWS CLI tools to be installed and configured which are used under the hood to transfer the data.
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user