Elliptics version update: 2.19.0.0
[elliptics.git] / example / ioserv.conf
bloba7a4ca982e0c5fd9fe9d06e4277d67833abeb24f
1 # log file
2 # set to 'syslog' without inverted commas if you want elliptics to log through syslog
3 log = /dev/stderr
5 # log level
6 # DNET_LOG_DATA         = 0
7 # DNET_LOG_ERROR        = 1
8 # DNET_LOG_INFO         = 2
9 # DNET_LOG_NOTICE       = 3
10 # DNET_LOG_DEBUG        = 4
11 #log_level = 2
12 log_level = 3
14 # specifies whether to join storage network
15 join = 1
17 # config flags
18 # bits start from 0, 0 is unused (its actuall above join flag)
19 # bit 1 - do not request remote route table
20 # bit 2 - mix states before read operations according to state's weights
21 # bit 3 - do not checksum data on upload and check it during data read
22 # bit 4 - do not update metadata at all
23 # bit 5 - randomize states for read requests
24 flags = 4
26 # node will join nodes in this group
27 group = 2
29 # list of remote nodes to connect
31 # address:port:family where family is either 2 (AF_INET) or 10 (AF_INET6)
32 # address can be host name or IP
34 # It is possible to autodiscover remote clusters via multicast
35 # If you put 'autodiscovery:address:port:family' where address:port:family is valid multicast address,
36 # elliptics will broadcast information about itself and remote nodes with the same auth cookie will
37 # receive this information and connect to given node. Multicast TTL equals to 3.
38 #remote = 1.2.3.4:1025:2 2.3.4.5:2345:2 autodiscovery:224.0.0.5:1025:2
40 # local address to bind to
41 # port 0 means random port
43 # one can use reserved word 'hostname' instead of local address (like hostname:1025:2)
44 # it will use hostname, the same as output of `hostname -f` command, as address
45 addr = localhost:1025:2
47 # wait timeout specifies number of seconds to wait for command completion
48 wait_timeout = 60
50 # this timeout specifies number of seconds to wait before killing
51 # unacked transaction
52 check_timeout = 60
54 # number of IO threads in processing pool
55 io_thread_num = 50
57 # number of IO threads in processing pool dedicated to nonblocking operations
58 # they are invoked from recursive commands like DNET_CMD_EXEC, when script
59 # tries to read/write some data using the same id/key as in original exec command
60 nonblocking_io_thread_num = 16
62 # number of thread in network processing pool
63 net_thread_num = 16
65 # specifies history environment directory
66 # it will host file with generated IDs
67 # and server-side execution scripts
68 history = /tmp/history
70 # specifies whether to go into background
71 daemon = 0
73 # authentication cookie
74 # if this string (32 bytes long max) does not match to server nodes,
75 # new node can not join and serve IO
76 auth_cookie = qwerty
78 # Background jobs (replica checks and recovery) IO priorities
79 # ionice for background operations (disk scheduler should support it)
80 # class - number from 0 to 3
81 # 0 - default class
82 # 1 - realtime class
83 # 2 - best-effort class
84 # 3 - idle class
85 bg_ionice_class = 3
86 # prio - number from 0 to 7, sets priority inside class
87 bg_ionice_prio = 0
89 # IP priorities
90 # man 7 socket for IP_PRIORITY
91 # server_net_prio is set for all joined (server) connections
92 # client_net_prio is set for other connection
93 # is only turned on when non zero
94 server_net_prio = 1
95 client_net_prio = 6
97 # Size of operation lock hash table
98 # These locks guard command execution, they are grabbed for allmost all operations
99 # except recursive (for example when DNET_CMD_EXEC reads or writes data) and some
100 # maintenance commands like statistics gathering and route table update
101 # Recovery process also runs without locks grabbed, since this locks operation quite
102 # for a long period of time, which may interfere with clients IO
103 oplock_num = 10240
105 # SRW - server-side scripting section
107 # srw worker config
108 # Elliptics uses cocaine engine (https://github.com/organizations/cocaine) for its server-side workers
109 # srw_config should point to its configuration file, example config lives in tree in example/library_config.json file
110 # srw_config = /opt/elliptics/library_config.json
112 # In-memory cache support
113 # This is maximum cache size. Cache is managed by LRU algorithm
114 # Using different IO flags in read/write/remove commands one can use it
115 # as cache for data, stored on disk (in configured backend),
116 # or as plain distributed in-memory cache
117 cache_size = 102400
119 # anything below this line will be processed
120 # by backend's parser and will not be able to
121 # change global configuration
123 # backend can be 'filesystem', 'blob' or 'smack'
125 backend = filesystem
127 # Number of bits (from the beginning of the object ID) used
128 # for directory, which hosts given object
129 directory_bit_number = 8
131 # Root directory for data objects
132 root = /tmp/root
134 # zero here means 'sync on every write'
135 # positive number means file writes are never synced
136 # and metadata is synced every @sync seconds
137 sync = 0
141 #backend = blob
143 # zero here means 'sync on every write'
144 # positive number means data amd metadata updates
145 # are synced every @sync seconds
146 #sync = 0
148 # eblob objects prefix. System will append .NNN and .NNN.index to new blobs
149 #data = /tmp/blob/data
151 # Align all writes to this boundary
152 #data_block_size = 1024
154 # blob processing flags (bits start from 0)
155 # bit 0 - if set, eblob reserves 10% of total space or size of the blob (which is bigger)
156 #               By default it is turned off and eblob only reserves size of the blob
157 #               This is useful (needed) to be able to run defragmentation
158 # bit 1 - overwrite commits write - when set, every overwrite operation will commit its size
159 #               To turn overwrite-commits mode you must turn on overwrite mode too, i.e. set bit 2 (blob_flags=6 in config file)
160 #               as final, otherwise we will just overwrite
161 #               Without this bit set it is equivalent to overwrite parts of the file
162 #               When this bit is set, it is like overwriting data and truncating file to given offset + size
163 # bit 2 - turn on overwrite mode - data can be overwritten in place instead
164 #               of appending it at the end. This mode is turned on for metadata
165 #               writes (column 1), this bit enables it for all other writes too
166 # bit 3 - do not append checksum footer - this saves 72 bytes per written record.
167 #               This also disables checksum.
168 # bit 4 - do not check whether system has enough space for the new blob
169 #blob_flags = 1
171 # Number of threads used to populate data into RAM at startup
172 #iterate_thread_num = 1
174 # Maximum blob size. New file will be opened after current one
175 # grows beyond @blob_size limit
176 # Supports K, M and G modifiers
177 #blob_size = 10G
179 # Maximum number of records in blob.
180 # When number of records reaches this level,
181 # blob is closed and sorted index is generated.
182 # Its meaning is similar to above @blob_size,
183 # except that it operates on records and not bytes.
184 records_in_blob = 10000000
186 # Timeout for defragmentation process to start
187 # In every time slot eblob will only defragment one blob,
188 # since system reserves enough space for only one blob
189 # After next timeout old (already defragmented into copy)
190 # blob will be closed (this will actually free space) and
191 # next one will be defragmented.
193 # Defragmentation operation is rather costly (even if nothing
194 # is going to be copied, defragmentation still checks every index
195 # to determine number of removed keys)
196 # It is recommended to set it to hours (it is in seconds) or more
197 # Default: -1 or none
198 defrag_timeout = 3600
200 # Percentage of removed entries (compared to number of all keys in blob)
201 # needed to start defragmentation. If number of removed keys is less than
202 # (removed + not removed) * $defrag_percentage / 100 then defragmentation
203 # process will skip given blob
204 defrag_percentage = 25
206 # backend = smack
207 # Smack is a high-performance backend for small-sized compressible data
208 # It was build with HBase data storage in mind
210 # Specifies Smack logger, if not set, main logfile is used
211 # log = /dev/stderr
213 # Supported compression types:
214 #   zlib - default zlib compression
215 #   zlib_best - best zlib compression, uses more CPU, but compresses data slightly better
216 #   bzip2 - much slower than zlib (2-3 times in small data sets, about 10-30% for large data sets, like hundreds on millions of records)
217 #           produces best compression, about 30% better compression ration than default zlib
218 #   snappy - google compression algorithm, is comparable in compression ratio with zlib default, but about 2 times faster
219 #   lz4_fast - LZ4 compression (http://code.google.com/p/lz4/) - fast compression algorithm
220 #   lz4_high - high compression ratio algorithm
222 # type = zlib
224 # Sync-to-disk interval (NOT YET SUPPORTED)
225 # sync = 300
227 # base directory, data files will look like $root/smack.$idx.data $root/smack.$idx.chunk
228 # root = /opt/elliptics/smack.2
230 # Each write goes into cache first, when cache reaches this limit, background thread picks blob and write cache to disk as a contiguous chunk
231 # The larger the value, the better write performance, but since chunk is compressed, read will have to uncompress it first
232 # So, the larger this cache size is, the larger is on-disk chunk where it is stored, and the slower uncompression and read performance are
233 # Cache is per blob, maximum number of blobs is specified in $blob_num variable
234 # This value likely should not be dramatically changed
235 # cache_size = 1000
237 # Size of the bloom filter in bytes - helps to quickly find if given record does not exist in the storage
238 # bloom_size = 1024
240 # Maximum number of blob files per storage
241 # Blob stores multiple data chunks and resorts whole content sometimes to ensure data is stored in a sorted order
242 # For fixed number of total records in the storage, the more blobs we have, the smaller is each blob's size,
243 # which means smaller resort times and thus faster writes
245 # Number of blobs MUST be sufficiently large so that every single blob could fit your RAM
246 # It is a good idea to set limit large enough so that several blobs fit memory
247 # blob_num = 50
249 # Number of background threads to write cache to disk and resort on-disk chunks
250 # On a heavily write-loaded systems small number of cache thread will not be able to quickly resort all written data
251 # It may be a good idea to set cache thread number to number of CPUs or slightly less (if processors are not supposed to be used
252 # for other tasks)
253 # cache_thread_num = 1