summaryrefslogtreecommitdiffstats
path: root/docs/guides/configure
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2022-11-30 18:47:00 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2022-11-30 18:47:00 +0000
commit03bf87dcb06f7021bfb2df2fa8691593c6148aff (patch)
treee16b06711a2ed77cafb4b7754be0220c3d14a9d7 /docs/guides/configure
parentAdding upstream version 1.36.1. (diff)
downloadnetdata-03bf87dcb06f7021bfb2df2fa8691593c6148aff.tar.xz
netdata-03bf87dcb06f7021bfb2df2fa8691593c6148aff.zip
Adding upstream version 1.37.0.upstream/1.37.0
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'docs/guides/configure')
-rw-r--r--docs/guides/configure/performance.md48
1 files changed, 44 insertions, 4 deletions
diff --git a/docs/guides/configure/performance.md b/docs/guides/configure/performance.md
index f8363416..cb52a114 100644
--- a/docs/guides/configure/performance.md
+++ b/docs/guides/configure/performance.md
@@ -8,8 +8,9 @@ custom_edit_url: https://github.com/netdata/netdata/edit/master/docs/guides/conf
# How to optimize the Netdata Agent's performance
We designed the Netdata Agent to be incredibly lightweight, even when it's collecting a few thousand dimensions every
-second and visualizing that data into hundreds of charts. The Agent itself should never use more than 1% of a single CPU
-core, roughly 100 MiB of RAM, and minimal disk I/O to collect, store, and visualize all this data.
+second and visualizing that data into hundreds of charts. When properly configured for a production node, the Agent
+itself should never use more than 1% of a single CPU core, roughly 50-100 MiB of RAM, and minimal disk I/O to collect,
+store, and visualize all this data.
We take this scalability seriously. We have one user [running
Netdata](https://github.com/netdata/netdata/issues/1323#issuecomment-266427841) on a system with 144 cores and 288
@@ -21,6 +22,11 @@ only 512 MiB of RAM, or an IoT device like a [Raspberry Pi](/docs/guides/monitor
cases, reducing Netdata's footprint beyond its already diminutive size can pay big dividends, giving your services more
horsepower while still monitoring the health and the performance of the node, OS, hardware, and applications.
+The default settings of the Netdata Agent are not optimized for performance, but for a simple standalone setup. We want
+the first install to give you something you can run without any configuration. Most of the settings and options are
+enabled, since we want you to experience the full thing.
+
+
## Prerequisites
- A node running the Netdata Agent.
@@ -146,18 +152,39 @@ calculator](/docs/store/change-metrics-storage.md#calculate-the-system-resources
All the settings are found in the `[global]` section of `netdata.conf`:
```conf
-[global]
+[db]
memory mode = dbengine
page cache size = 32
dbengine multihost disk space = 256
```
+To save even more memory, you can disable the dbengine and reduce retention to just 30 minutes, as shown below:
+
+```conf
+[db]
+ storage tiers = 1
+ mode = alloc
+ retention = 1800
+```
+
Metric retention is not important in certain use cases, such as:
- Data collection nodes stream collected metrics collected to a centralization point.
- Data collection nodes export their metrics to another time series DB, or are scraped by Prometheus
- Netdata installed only during incidents, to get richer information.
-In such cases, you may not want to use the dbengine at all and instead opt for memory mode `memory mode = ram` or `memory mode = none`.
+In such cases, you may not want to use the dbengine at all and instead opt for memory mode
+`memory mode = alloc` or `memory mode = none`.
+
+## Disable machine learning
+
+Automated anomaly detection may be a powerful tool, but we recommend it to only be enabled on Netdata parents
+that sit outside your production infrastructure, or if you have cpu and memory to spare. You can disable ML
+with the following:
+```conf
+[ml]
+ enabled = no
+```
+
## Run Netdata behind Nginx
A dedicated web server like Nginx provides far more robustness than the Agent's internal [web server](/web/README.md).
@@ -220,6 +247,19 @@ If you installation is working correctly, and you're not actively auditing Netda
access log = none
```
+## Disable health checks
+
+If you are streaming metrics to parent nodes, we recommend you run your health checks on the parent, for all the metrics collected
+by the children nodes. This saves resources on the children and makes it easier to configure or disable alerts and agent notifications.
+
+The parents by default run health checks for each child, as long as it is connected (the details are in `stream.conf`).
+On the child nodes you should add to `netdata.conf` the following:
+
+```conf
+[health]
+ enabled = no
+```
+
## What's next?
We hope this guide helped you better understand how to optimize the performance of the Netdata Agent.