Update change-metrics-storage.md (#15896)
* Update change-metrics-storage.md * Update docs/store/change-metrics-storage.md Co-authored-by: Emmanuel Vasilakis <mrzammler@mm.st> --------- Co-authored-by: Emmanuel Vasilakis <mrzammler@mm.st>
Fotis Voutsas committed
Sep 4, 2023 at 13:56 UTC
968642701e0e05e6e22d5aadb05ce841a54c60ea
1 file changed
+12
-12
docs/store/change-metrics-storage.md
+12
-12
@@ -43,8 +43,8 @@ we will have a data point every minute in tier 1 and every minute in tier 2.
43
Up to 5 tiers are supported. You may add, or remove tiers and/or modify these multipliers, as long as the
44
product of all the "update every iterations" does not exceed 65535 (number of points for each tier0 point).
45
46
-e.g. If you simply add a fourth tier by setting `storage tiers = 4` and defining the disk space for the new tier,
47
-the product of the "update every iterations" will be 60 * 60 * 60 = 216,000, which is > 65535. So you'd need to reduce
46
+e.g. If you simply add a fourth tier by setting `storage tiers = 4` and define the disk space for the new tier,
47
+the product of the "update every iterations" will be 60 \* 60 \* 60 = 216,000, which is > 65535. So you'd need to reduce
48
the `update every iterations` of the tiers, to stay under the limit.
49
50
The exact retention that can be achieved by each tier depends on the number of metrics collected. The more
@@ -163,6 +163,16 @@ Save the file and restart the Agent with `sudo systemctl restart netdata`, or
163
the [appropriate method](https://github.com/netdata/netdata/blob/master/docs/configure/start-stop-restart.md)
164
for your system, to change the database engine's size.
165
166
+## Scaling dedicated parent nodes
167
+
168
+When you use streaming in medium to large infrastructures, you can have potentially millions of metrics per second reaching each parent node.
169
+In the lab we have reliably collected 1 million metrics/sec with 16cores and 32GB RAM.
170
+
171
+Our suggestion for scaling parents is to have them running on dedicated VMs, using a maximum of 50% of cpu, and ensuring you have enough RAM
172
+for the desired retention. When your infrastructure can lead a parent to exceed these characteristics, split the load to multiple parents that
173
+do not communicate with each other. With each child sending data to only one of the parents, you can still have replication, high availability,
174
+and infrastructure level observability via the Netdata Cloud UI.
175
+
176
## Legacy configuration
177
178
### v1.35.1 and prior
@@ -195,13 +205,3 @@ All new child nodes are automatically transferred to the multihost dbengine inst
205
space. If you want to migrate a child node from its legacy dbengine instance to the multihost dbengine instance, you
206
must delete the instance's directory, which is located in `/var/cache/netdata/MACHINE_GUID/dbengine`, after stopping the
207
Agent.
198
-
199
-## Scaling dedicated parent nodes
200
-
201
-When you use streaming in medium to large infrastructures, you can have potentially millions of metrics per second reaching each parent node.
202
-In the lab we have reliably collected 1 million metrics/sec with 16cores and 32GB RAM.
203
-
204
-Our suggestion for scaling parents is to have them running on dedicated VMs, using a maximum of 50% of cpu, and ensuring you have enough RAM
205
-for the desired retention. When your infrastructure can lead a parent to exceed these characteristics, split the load to multiple parents that
206
-do not communicate with each other. With each child sending data to only one of the parents, you can still have replication, high availability,
207
-and infrastructure level observability via the Netdata Cloud UI.