Fix Remark Lint for READMEs in Database (#6942)
* fix remark lint Database engine * fix remark lint of database README * rewrap dbengine readme for consistency * rewrap database README * make character limit to 120 not 80
Promise Akpan committed
Sep 29, 2019 at 08:48 UTC
8982b9968e9763567ce1a20acca49c794dc91f9d
2 files changed
+159
-175
database/README.md
+98
-105
@@ -1,59 +1,53 @@
1
# Database
2
3
-Although `netdata` does all its calculations using `long double`, it stores all values using
4
-a [custom-made 32-bit number](../libnetdata/storage_number/).
3
+Although `netdata` does all its calculations using `long double`, it stores all values using a [custom-made 32-bit
4
+number](../libnetdata/storage_number/).
5
6
-So, for each dimension of a chart, Netdata will need: `4 bytes for the value * the entries
7
-of its history`. It will not store any other data for each value in the time series database.
8
-Since all its values are stored in a time series with fixed step, the time each value
9
-corresponds can be calculated at run time, using the position of a value in the round robin database.
6
+So, for each dimension of a chart, Netdata will need: `4 bytes for the value * the entries of its history`. It will not
7
+store any other data for each value in the time series database. Since all its values are stored in a time series with
8
+fixed step, the time each value corresponds can be calculated at run time, using the position of a value in the round
9
+robin database.
10
11
-The default history is 3.600 entries, thus it will need 14.4KB for each chart dimension.
12
-If you need 1.000 dimensions, they will occupy just 14.4MB.
11
+The default history is 3.600 entries, thus it will need 14.4KB for each chart dimension. If you need 1.000 dimensions,
12
+they will occupy just 14.4MB.
13
14
-Of course, 3.600 entries is a very short history, especially if data collection frequency is set
15
-to 1 second. You will have just one hour of data.
14
+Of course, 3.600 entries is a very short history, especially if data collection frequency is set to 1 second. You will
15
+have just one hour of data.
16
17
-For a day of data and 1.000 dimensions, you will need: 86.400 seconds * 4 bytes * 1.000
18
-dimensions = 345MB of RAM.
17
+For a day of data and 1.000 dimensions, you will need: `86.400 seconds * 4 bytes * 1.000 dimensions = 345MB of RAM`.
18
20
-One option you have to lower this number is to use
21
-**[Memory Deduplication - Kernel Same Page Merging - KSM](#ksm)**. Another possibility is to
22
-use the **[Database Engine](engine/)**.
19
+One option you have to lower this number is to use **[Memory Deduplication - Kernel Same Page Merging - KSM](#ksm)**.
20
+Another possibility is to use the **[Database Engine](engine/)**.
21
22
## Memory modes
23
24
Currently Netdata supports 6 memory modes:
25
28
-1. `ram`, data are purely in memory. Data are never saved on disk. This mode uses `mmap()` and
29
- supports [KSM](#ksm).
26
+1. `ram`, data are purely in memory. Data are never saved on disk. This mode uses `mmap()` and supports [KSM](#ksm).
27
31
-2. `save`, (the default) data are only in RAM while Netdata runs and are saved to / loaded from
32
- disk on Netdata restart. It also uses `mmap()` and supports [KSM](#ksm).
28
+2. `save`, (the default) data are only in RAM while Netdata runs and are saved to / loaded from disk on Netdata
29
+ restart. It also uses `mmap()` and supports [KSM](#ksm).
30
34
-3. `map`, data are in memory mapped files. This works like the swap. Keep in mind though, this
35
- will have a constant write on your disk. When Netdata writes data on its memory, the Linux kernel
36
- marks the related memory pages as dirty and automatically starts updating them on disk.
37
- Unfortunately we cannot control how frequently this works. The Linux kernel uses exactly the
38
- same algorithm it uses for its swap memory. Check below for additional information on running a
39
- dedicated central Netdata server. This mode uses `mmap()` but does not support [KSM](#ksm).
31
+3. `map`, data are in memory mapped files. This works like the swap. Keep in mind though, this will have a constant
32
+ write on your disk. When Netdata writes data on its memory, the Linux kernel marks the related memory pages as dirty
33
+ and automatically starts updating them on disk. Unfortunately we cannot control how frequently this works. The Linux
34
+ kernel uses exactly the same algorithm it uses for its swap memory. Check below for additional information on
35
+ running a dedicated central Netdata server. This mode uses `mmap()` but does not support [KSM](#ksm).
36
37
4. `none`, without a database (collected metrics can only be streamed to another Netdata).
38
43
-5. `alloc`, like `ram` but it uses `calloc()` and does not support [KSM](#ksm). This mode is the
44
- fallback for all others except `none`.
39
+5. `alloc`, like `ram` but it uses `calloc()` and does not support [KSM](#ksm). This mode is the fallback for all
40
+ others except `none`.
41
46
-6. `dbengine`, data are in database files. The [Database Engine](engine/) works like a traditional
47
- database. There is some amount of RAM dedicated to data caching and indexing and the rest of
48
- the data reside compressed on disk. The number of history entries is not fixed in this case,
49
- but depends on the configured disk space and the effective compression ratio of the data stored.
50
- This is the **only mode** that supports changing the data collection update frequency
51
- (`update_every`) **without losing** the previously stored metrics.
52
- For more details see [here](engine/).
42
+6. `dbengine`, data are in database files. The [Database Engine](engine/) works like a traditional database. There is
43
+ some amount of RAM dedicated to data caching and indexing and the rest of the data reside compressed on disk. The
44
+ number of history entries is not fixed in this case, but depends on the configured disk space and the effective
45
+ compression ratio of the data stored. This is the **only mode** that supports changing the data collection update
46
+ frequency (`update_every`) **without losing** the previously stored metrics. For more details see [here](engine/).
47
48
You can select the memory mode by editing `netdata.conf` and setting:
49
56
-```
50
+```conf
51
[global]
52
# ram, save (the default, save on exit, load on start), map (swap like)
53
memory mode = save
@@ -71,62 +65,58 @@ There are 2 settings for you to tweak:
65
1. `update every`, which controls the data collection frequency
66
2. `history`, which controls the size of the database in RAM
67
74
-By default `update every = 1` and `history = 3600`. This gives you an hour of data with per
75
-second updates.
68
+By default `update every = 1` and `history = 3600`. This gives you an hour of data with per second updates.
69
77
-If you set `update every = 2` and `history = 1800`, you will still have an hour of data, but
78
-collected once every 2 seconds. This will **cut in half** both CPU and RAM resources consumed
79
-by Netdata. Of course experiment a bit. On very weak devices you might have to use
80
-`update every = 5` and `history = 720` (still 1 hour of data, but 1/5 of the CPU and RAM resources).
70
+If you set `update every = 2` and `history = 1800`, you will still have an hour of data, but collected once every 2
71
+seconds. This will **cut in half** both CPU and RAM resources consumed by Netdata. Of course experiment a bit. On very
72
+weak devices you might have to use `update every = 5` and `history = 720` (still 1 hour of data, but 1/5 of the CPU and
73
+RAM resources).
74
82
-You can also disable [data collection plugins](../collectors) you don't need.
83
-Disabling such plugins will also free both CPU and RAM resources.
75
+You can also disable [data collection plugins](../collectors) you don't need. Disabling such plugins will also free both
76
+CPU and RAM resources.
77
78
## Running a dedicated central Netdata server
79
87
-Netdata allows streaming data between Netdata nodes. This allows us to have a central Netdata
88
-server that will maintain the entire database for all nodes, and will also run health checks/alarms
89
-for all nodes.
80
+Netdata allows streaming data between Netdata nodes. This allows us to have a central Netdata server that will maintain
81
+the entire database for all nodes, and will also run health checks/alarms for all nodes.
82
91
-For this central Netdata, memory size can be a problem. Fortunately, Netdata supports several
92
-memory modes. **One interesting option** for this setup is `memory mode = map`.
83
+For this central Netdata, memory size can be a problem. Fortunately, Netdata supports several memory modes. **One
84
+interesting option** for this setup is `memory mode = map`.
85
86
### map
87
96
-In this mode, the database of Netdata is stored in memory mapped files. Netdata continues to read
97
-and write the database in memory, but the kernel automatically loads and saves memory pages from/to
98
-disk.
88
+In this mode, the database of Netdata is stored in memory mapped files. Netdata continues to read and write the database
89
+in memory, but the kernel automatically loads and saves memory pages from/to disk.
90
100
-**We suggest _not_ to use this mode on nodes that run other applications.** There will always be
101
-dirty memory to be synced and this syncing process may influence the way other applications work.
102
-This mode however is useful when we need a central Netdata server that would normally need huge
103
-amounts of memory. Using memory mode `map` we can overcome all memory restrictions.
91
+**We suggest _not_ to use this mode on nodes that run other applications.** There will always be dirty memory to be
92
+synced and this syncing process may influence the way other applications work. This mode however is useful when we need
93
+a central Netdata server that would normally need huge amounts of memory. Using memory mode `map` we can overcome all
94
+memory restrictions.
95
105
-There are a few kernel options that provide finer control on the way this syncing works. But before
106
-explaining them, a brief introduction of how Netdata database works is needed.
96
+There are a few kernel options that provide finer control on the way this syncing works. But before explaining them, a
97
+brief introduction of how Netdata database works is needed.
98
99
For each chart, Netdata maps the following files:
100
110
-1. `chart/main.db`, this is the file that maintains chart information. Every time data are collected
111
- for a chart, this is updated.
112
-2. `chart/dimension_name.db`, this is the file for each dimension. At its beginning there is a
113
- header, followed by the round robin database where metrics are stored.
101
+1. `chart/main.db`, this is the file that maintains chart information. Every time data are collected for a chart, this
102
+ is updated.
103
+2. `chart/dimension_name.db`, this is the file for each dimension. At its beginning there is a header, followed by the
104
+ round robin database where metrics are stored.
105
106
So, every time Netdata collects data, the following pages will become dirty:
107
108
1. the chart file
109
2. the header part of all dimension files
119
-3. if the collected metrics are stored far enough in the dimension file, another page will
120
- become dirty, for each dimension
110
+3. if the collected metrics are stored far enough in the dimension file, another page will become dirty, for each
111
+ dimension
112
122
-Each page in Linux is 4KB. So, with 200 charts and 1000 dimensions, there will be 1200 to 2200 4KB
123
-pages dirty pages every second. Of course 1200 of them will always be dirty (the chart header and
124
-the dimensions headers) and 1000 will be dirty for about 1000 seconds (4 bytes per metric, 4KB per
125
-page, so 1000 seconds, or 16 minutes per page).
113
+Each page in Linux is 4KB. So, with 200 charts and 1000 dimensions, there will be 1200 to 2200 4KB pages dirty pages
114
+every second. Of course 1200 of them will always be dirty (the chart header and the dimensions headers) and 1000 will be
115
+dirty for about 1000 seconds (4 bytes per metric, 4KB per page, so 1000 seconds, or 16 minutes per page).
116
127
-Hopefully, the Linux kernel does not sync all these data every second. The frequency they are
128
-synced is controlled by `/proc/sys/vm/dirty_expire_centisecs` or the
129
-`sysctl` `vm.dirty_expire_centisecs`. The default on most systems is 3000 (30 seconds).
117
+Hopefully, the Linux kernel does not sync all these data every second. The frequency they are synced is controlled by
118
+`/proc/sys/vm/dirty_expire_centisecs` or the `sysctl` `vm.dirty_expire_centisecs`. The default on most systems is 3000
119
+(30 seconds).
120
121
On a busy server centralizing metrics from 20+ servers you will experience this:
122
@@ -134,62 +124,59 @@ On a busy server centralizing metrics from 20+ servers you will experience this:
124
125
As you can see, there is quite some stress (this is `iowait`) every 30 seconds.
126
137
-A simple solution is to increase this time to 10 minutes (60000). This is the same system
138
-with this setting in 10 minutes:
127
+A simple solution is to increase this time to 10 minutes (60000). This is the same system with this setting in 10
128
+minutes:
129
130
131
142
-Of course, setting this to 10 minutes means that data on disk might be up to 10 minutes old if you
143
-get an abnormal shutdown.
132
+Of course, setting this to 10 minutes means that data on disk might be up to 10 minutes old if you get an abnormal
133
+shutdown.
134
135
There are 2 more options to tweak:
136
137
1. `dirty_background_ratio`, by default `10`.
138
2. `dirty_ratio`, by default `20`.
139
150
-These control the amount of memory that should be dirty for disk syncing to be triggered.
151
-On dedicated Netdata servers, you can use: `80` and `90` respectively, so that all RAM is given
152
-to Netdata.
140
+These control the amount of memory that should be dirty for disk syncing to be triggered. On dedicated Netdata servers,
141
+you can use: `80` and `90` respectively, so that all RAM is given to Netdata.
142
154
-With these settings, you can expect a little `iowait` spike once every 10 minutes and in case
155
-of system crash, data on disk will be up to 10 minutes old.
143
+With these settings, you can expect a little `iowait` spike once every 10 minutes and in case of system crash, data on
144
+disk will be up to 10 minutes old.
145
146
147
159
-To have these settings automatically applied on boot, create the file `/etc/sysctl.d/netdata-memory.conf` with these contents:
148
+To have these settings automatically applied on boot, create the file `/etc/sysctl.d/netdata-memory.conf` with these
149
+contents:
150
161
-```
151
+```conf
152
vm.dirty_expire_centisecs = 60000
153
vm.dirty_background_ratio = 80
154
vm.dirty_ratio = 90
155
vm.dirty_writeback_centisecs = 0
156
```
157
168
-There is another memory mode to help overcome the memory size problem. What is **most interesting
169
-for this setup** is `memory mode = dbengine`.
158
+There is another memory mode to help overcome the memory size problem. What is **most interesting for this setup** is
159
+`memory mode = dbengine`.
160
161
### dbengine
162
173
-In this mode, the database of Netdata is stored in database files. The [Database Engine](engine/)
174
-works like a traditional database. There is some amount of RAM dedicated to data caching and
175
-indexing and the rest of the data reside compressed on disk. The number of history entries is not
176
-fixed in this case, but depends on the configured disk space and the effective compression ratio
177
-of the data stored.
163
+In this mode, the database of Netdata is stored in database files. The [Database Engine](engine/) works like a
164
+traditional database. There is some amount of RAM dedicated to data caching and indexing and the rest of the data reside
165
+compressed on disk. The number of history entries is not fixed in this case, but depends on the configured disk space
166
+and the effective compression ratio of the data stored.
167
179
-We suggest to use **this** mode on nodes that also run other applications. The Database Engine uses
180
-direct I/O to avoid polluting the OS filesystem caches and does not generate excessive I/O traffic
181
-so as to create the minimum possible interference with other applications. Using memory mode
182
-`dbengine` we can overcome most memory restrictions. For more details see [here](engine/).
168
+We suggest to use **this** mode on nodes that also run other applications. The Database Engine uses direct I/O to avoid
169
+polluting the OS filesystem caches and does not generate excessive I/O traffic so as to create the minimum possible
170
+interference with other applications. Using memory mode `dbengine` we can overcome most memory restrictions. For more
171
+details see [here](engine/).
172
173
## KSM
174
186
-Netdata offers all its round robin database to kernel for deduplication
187
-(except for `memory mode = dbengine`).
175
+Netdata offers all its round robin database to kernel for deduplication (except for `memory mode = dbengine`).
176
189
-In the past KSM has been criticized for consuming a lot of CPU resources.
190
-Although this is true when KSM is used for deduplicating certain applications, it is not true with
191
-netdata, since the Netdata memory is written very infrequently (if you have 24 hours of metrics in
192
-netdata, each byte at the in-memory database will be updated just once per day).
177
+In the past KSM has been criticized for consuming a lot of CPU resources. Although this is true when KSM is used for
178
+deduplicating certain applications, it is not true with netdata, since the Netdata memory is written very infrequently
179
+(if you have 24 hours of metrics in netdata, each byte at the in-memory database will be updated just once per day).
180
181
KSM is a solution that will provide 60+% memory savings to Netdata.
182
@@ -203,15 +190,20 @@ CONFIG_KSM=y
190
191
When KSM is enabled at the kernel is just available for the user to enable it.
192
206
-So, if you build a kernel with `CONFIG_KSM=y` you will just get a few files in `/sys/kernel/mm/ksm`. Nothing else happens. There is no performance penalty (apart I guess from the memory this code occupies into the kernel).
193
+So, if you build a kernel with `CONFIG_KSM=y` you will just get a few files in `/sys/kernel/mm/ksm`. Nothing else
194
+happens. There is no performance penalty (apart I guess from the memory this code occupies into the kernel).
195
196
The files that `CONFIG_KSM=y` offers include:
197
210
-- `/sys/kernel/mm/ksm/run` by default `0`. You have to set this to `1` for the kernel to spawn `ksmd`.
211
-- `/sys/kernel/mm/ksm/sleep_millisecs`, by default `20`. The frequency ksmd should evaluate memory for deduplication.
212
-- `/sys/kernel/mm/ksm/pages_to_scan`, by default `100`. The amount of pages ksmd will evaluate on each run.
198
+- `/sys/kernel/mm/ksm/run` by default `0`. You have to set this to `1` for the
199
+ kernel to spawn `ksmd`.
200
+- `/sys/kernel/mm/ksm/sleep_millisecs`, by default `20`. The frequency ksmd
201
+ should evaluate memory for deduplication.
202
+- `/sys/kernel/mm/ksm/pages_to_scan`, by default `100`. The amount of pages
203
+ ksmd will evaluate on each run.
204
214
-So, by default `ksmd` is just disabled. It will not harm performance and the user/admin can control the CPU resources he/she is willing `ksmd` to use.
205
+So, by default `ksmd` is just disabled. It will not harm performance and the user/admin can control the CPU resources
206
+he/she is willing `ksmd` to use.
207
208
### Run `ksmd` kernel daemon
209
@@ -222,7 +214,8 @@ echo 1 >/sys/kernel/mm/ksm/run
214
echo 1000 >/sys/kernel/mm/ksm/sleep_millisecs
215
```
216
225
-With these settings ksmd does not even appear in the running process list (it will run once per second and evaluate 100 pages for de-duplication).
217
+With these settings ksmd does not even appear in the running process list (it will run once per second and evaluate 100
218
+pages for de-duplication).
219
220
Put the above lines in your boot sequence (`/etc/rc.local` or equivalent) to have `ksmd` run at boot.
221
@@ -232,4 +225,4 @@ Netdata will create charts for kernel memory de-duplication performance, like th
225
226
227
235
-[](<>)
228
+[](<>)
\ No newline at end of file
database/engine/README.md
+61
-70
@@ -1,18 +1,17 @@
1
# Database engine
2
3
-The Database Engine works like a traditional
4
-database. There is some amount of RAM dedicated to data caching and indexing and the rest of
5
-the data reside compressed on disk. The number of history entries is not fixed in this case,
6
-but depends on the configured disk space and the effective compression ratio of the data stored.
7
-This is the **only mode** that supports changing the data collection update frequency
8
-(`update_every`) **without losing** the previously stored metrics.
3
+The Database Engine works like a traditional database. There is some amount of RAM dedicated to data caching and
4
+indexing and the rest of the data reside compressed on disk. The number of history entries is not fixed in this case,
5
+but depends on the configured disk space and the effective compression ratio of the data stored. This is the **only
6
+mode** that supports changing the data collection update frequency (`update_every`) **without losing** the previously
7
+stored metrics.
8
9
## Files
10
12
-With the DB engine memory mode the metric data are stored in database files. These files are
13
-organized in pairs, the datafiles and their corresponding journalfiles, e.g.:
11
+With the DB engine memory mode the metric data are stored in database files. These files are organized in pairs, the
12
+datafiles and their corresponding journalfiles, e.g.:
13
15
-```
14
+```sh
15
datafile-1-0000000001.ndf
16
journalfile-1-0000000001.njf
17
datafile-1-0000000002.ndf
@@ -22,21 +21,19 @@ journalfile-1-0000000003.njf
21
...
22
```
23
25
-They are located under their host's cache directory in the directory `./dbengine`
26
-(e.g. for localhost the default location is `/var/cache/netdata/dbengine/*`). The higher
27
-numbered filenames contain more recent metric data. The user can safely delete some pairs
28
-of files when Netdata is stopped to manually free up some space.
24
+They are located under their host's cache directory in the directory `./dbengine` (e.g. for localhost the default
25
+location is `/var/cache/netdata/dbengine/*`). The higher numbered filenames contain more recent metric data. The user
26
+can safely delete some pairs of files when Netdata is stopped to manually free up some space.
27
28
_Users should_ **back up** _their `./dbengine` folders if they consider this data to be important._
29
30
## Configuration
31
34
-There is one DB engine instance per Netdata host/node. That is, there is one `./dbengine` folder
35
-per node, and all charts of `dbengine` memory mode in such a host share the same storage space
36
-and DB engine instance memory state. You can select the memory mode for localhost by editing
37
-netdata.conf and setting:
32
+There is one DB engine instance per Netdata host/node. That is, there is one `./dbengine` folder per node, and all
33
+charts of `dbengine` memory mode in such a host share the same storage space and DB engine instance memory state. You
34
+can select the memory mode for localhost by editing netdata.conf and setting:
35
39
-```
36
+```conf
37
[global]
38
memory mode = dbengine
39
```
@@ -44,57 +41,52 @@ netdata.conf and setting:
41
For setting the memory mode for the rest of the nodes you should look at
42
[streaming](../../streaming/).
43
47
-The `history` configuration option is meaningless for `memory mode = dbengine` and is ignored
48
-for any metrics being stored in the DB engine.
44
+The `history` configuration option is meaningless for `memory mode = dbengine` and is ignored for any metrics being
45
+stored in the DB engine.
46
50
-All DB engine instances, for localhost and all other streaming recipient nodes inherit their
51
-configuration from `netdata.conf`:
47
+All DB engine instances, for localhost and all other streaming recipient nodes inherit their configuration from
48
+`netdata.conf`:
49
53
-```
50
+```conf
51
[global]
52
page cache size = 32
53
dbengine disk space = 256
54
```
55
59
-The above values are the default and minimum values for Page Cache size and DB engine disk space
60
-quota. Both numbers are in **MiB**. All DB engine instances will allocate the configured resources
61
-separately.
56
+The above values are the default and minimum values for Page Cache size and DB engine disk space quota. Both numbers are
57
+in **MiB**. All DB engine instances will allocate the configured resources separately.
58
63
-The `page cache size` option determines the amount of RAM in **MiB** that is dedicated to caching
64
-Netdata metric values themselves.
59
+The `page cache size` option determines the amount of RAM in **MiB** that is dedicated to caching Netdata metric values
60
+themselves.
61
66
-The `dbengine disk space` option determines the amount of disk space in **MiB** that is dedicated
67
-to storing Netdata metric values and all related metadata describing them.
62
+The `dbengine disk space` option determines the amount of disk space in **MiB** that is dedicated to storing Netdata
63
+metric values and all related metadata describing them.
64
65
## Operation
66
71
-The DB engine stores chart metric values in 4096-byte pages in memory. Each chart dimension gets
72
-its own page to store consecutive values generated from the data collectors. Those pages comprise
73
-the **Page Cache**.
67
+The DB engine stores chart metric values in 4096-byte pages in memory. Each chart dimension gets its own page to store
68
+consecutive values generated from the data collectors. Those pages comprise the **Page Cache**.
69
75
-When those pages fill up they are slowly compressed and flushed to disk.
76
-It can take `4096 / 4 = 1024 seconds = 17 minutes`, for a chart dimension that is being collected
77
-every 1 second, to fill a page. Pages can be cut short when we stop Netdata or the DB engine
78
-instance so as to not lose the data. When we query the DB engine for data we trigger disk read
79
-I/O requests that fill the Page Cache with the requested pages and potentially evict cold
80
-(not recently used) pages.
70
+When those pages fill up they are slowly compressed and flushed to disk. It can take `4096 / 4 = 1024 seconds = 17
71
+minutes`, for a chart dimension that is being collected every 1 second, to fill a page. Pages can be cut short when we
72
+stop Netdata or the DB engine instance so as to not lose the data. When we query the DB engine for data we trigger disk
73
+read I/O requests that fill the Page Cache with the requested pages and potentially evict cold (not recently used)
74
+pages.
75
82
-When the disk quota is exceeded the oldest values are removed from the DB engine at real time, by
83
-automatically deleting the oldest datafile and journalfile pair. Any corresponding pages residing
84
-in the Page Cache will also be invalidated and removed. The DB engine logic will try to maintain
85
-between 10 and 20 file pairs at any point in time.
76
+When the disk quota is exceeded the oldest values are removed from the DB engine at real time, by automatically deleting
77
+the oldest datafile and journalfile pair. Any corresponding pages residing in the Page Cache will also be invalidated
78
+and removed. The DB engine logic will try to maintain between 10 and 20 file pairs at any point in time.
79
87
-The Database Engine uses direct I/O to avoid polluting the OS filesystem caches and does not
88
-generate excessive I/O traffic so as to create the minimum possible interference with other
89
-applications.
80
+The Database Engine uses direct I/O to avoid polluting the OS filesystem caches and does not generate excessive I/O
81
+traffic so as to create the minimum possible interference with other applications.
82
83
## Memory requirements
84
93
-Using memory mode `dbengine` we can overcome most memory restrictions and store a dataset that
94
-is much larger than the available memory.
85
+Using memory mode `dbengine` we can overcome most memory restrictions and store a dataset that is much larger than the
86
+available memory.
87
96
-There are explicit memory requirements **per** DB engine **instance**, meaning **per** Netdata
97
-**node** (e.g. localhost and streaming recipient nodes):
88
+There are explicit memory requirements **per** DB engine **instance**, meaning **per** Netdata **node** (e.g. localhost
89
+and streaming recipient nodes):
90
91
- `page cache size` must be at least `#dimensions-being-collected x 4096 x 2` bytes.
92
@@ -102,48 +94,47 @@ There are explicit memory requirements **per** DB engine **instance**, meaning *
94
95
- roughly speaking this is 3% of the uncompressed disk space taken by the DB files.
96
105
- - for very highly compressible data (compression ratio > 90%) this RAM overhead
106
- is comparable to the disk space footprint.
97
+ - for very highly compressible data (compression ratio > 90%) this RAM overhead is comparable to the disk space
98
+ footprint.
99
108
-An important observation is that RAM usage depends on both the `page cache size` and the
109
-`dbengine disk space` options.
100
+An important observation is that RAM usage depends on both the `page cache size` and the `dbengine disk space` options.
101
102
## File descriptor requirements
103
113
-The Database Engine may keep a **significant** amount of files open per instance (e.g. per streaming
114
-slave or master server). When configuring your system you should make sure there are at least 50
115
-file descriptors available per `dbengine` instance.
104
+The Database Engine may keep a **significant** amount of files open per instance (e.g. per streaming slave or master
105
+server). When configuring your system you should make sure there are at least 50 file descriptors available per
106
+`dbengine` instance.
107
117
-Netdata allocates 25% of the available file descriptors to its Database Engine instances. This means that only 25%
118
-of the file descriptors that are available to the Netdata service are accessible by dbengine instances.
119
-You should take that into account when configuring your service
120
-or system-wide file descriptor limits. You can roughly estimate that the Netdata service needs 2048 file
121
-descriptors for every 10 streaming slave hosts when streaming is configured to use `memory mode = dbengine`.
108
+Netdata allocates 25% of the available file descriptors to its Database Engine instances. This means that only 25% of
109
+the file descriptors that are available to the Netdata service are accessible by dbengine instances. You should take
110
+that into account when configuring your service or system-wide file descriptor limits. You can roughly estimate that the
111
+Netdata service needs 2048 file descriptors for every 10 streaming slave hosts when streaming is configured to use
112
+`memory mode = dbengine`.
113
123
-If for example one wants to allocate 65536 file descriptors to the Netdata service on a systemd system
124
-one needs to override the Netdata service by running `sudo systemctl edit netdata` and creating a
125
-file with contents:
114
+If for example one wants to allocate 65536 file descriptors to the Netdata service on a systemd system one needs to
115
+override the Netdata service by running `sudo systemctl edit netdata` and creating a file with contents:
116
127
-```
117
+```sh
118
[Service]
119
LimitNOFILE=65536
120
```
121
122
For other types of services one can add the line:
123
134
-```
124
+```sh
125
ulimit -n 65536
126
```
127
138
-at the beginning of the service file. Alternatively you can change the system-wide limits of the kernel by changing `/etc/sysctl.conf`. For linux that would be:
128
+at the beginning of the service file. Alternatively you can change the system-wide limits of the kernel by changing
129
+ `/etc/sysctl.conf`. For linux that would be:
130
140
-```
131
+```conf
132
fs.file-max = 65536
133
```
134
135
In FreeBSD and OS X you change the lines like this:
136
146
-```
137
+```conf
138
kern.maxfilesperproc=65536
139
kern.maxfiles=65536
140
```