mirror of
https://github.com/netdata/netdata.git
synced 2025-05-16 14:21:40 +00:00
docs: grammar/format fixes to docs/netdata-agent/
(#18942)
This commit is contained in:
parent
8af00b9dbe
commit
20a280aeb4
14 changed files with 113 additions and 115 deletions
docs/netdata-agent/sizing-netdata-agents
|
@ -1,16 +1,16 @@
|
|||
# Bandwidth Requirements
|
||||
|
||||
## On Production Systems, Standalone Netdata
|
||||
## Production Systems: Standalone Netdata
|
||||
|
||||
Standalone Netdata may use network bandwidth under the following conditions:
|
||||
|
||||
1. You configured data collection jobs that are fetching data from remote systems. There is no such jobs enabled by default.
|
||||
1. You configured data collection jobs that are fetching data from remote systems. There are no such jobs enabled by default.
|
||||
2. You use the dashboard of the Netdata.
|
||||
3. [Netdata Cloud communication](#netdata-cloud-communication) (see below).
|
||||
|
||||
## On Metrics Centralization Points, between Netdata Children & Parents
|
||||
## Metrics Centralization Points: Between Netdata Children & Parents
|
||||
|
||||
Netdata supports multiple compression algorithms for streaming communication. Netdata Children offer all their compression algorithms when connecting to a Netdata Parent, and the Netdata Parent decides which one to use based on algorithms availability and user configuration.
|
||||
Netdata supports multiple compression algorithms for streaming communication. Netdata Children offer all their compression algorithms when connecting to a Netdata Parent, and the Netdata Parent decides which one to use based on algorithm availability and user configuration.
|
||||
|
||||
| Algorithm | Best for |
|
||||
|:---------:|:-----------------------------------------------------------------------------------------------------------------------------------:|
|
||||
|
@ -42,6 +42,6 @@ The information transferred to Netdata Cloud is:
|
|||
3. Information about the **metrics available and their retention**.
|
||||
4. Information about the **configured alerts and their transitions**.
|
||||
|
||||
This is not a constant stream of information. Netdata Agents update Netdata Cloud only about status changes on all the above (e.g. an alert being triggered, or a metric stopped being collected). So, there is an initial handshake and exchange of information when Netdata starts, and then there only updates when required.
|
||||
This is not a constant stream of information. Netdata Agents update Netdata Cloud only about status changes on all the above (e.g., an alert being triggered, or a metric stopped being collected). So, there is an initial handshake and exchange of information when Netdata starts, and then there only updates when required.
|
||||
|
||||
Of course, when you view Netdata Cloud dashboards that need to query the database a Netdata agent maintains, this query is forwarded to an agent that can satisfy it. This means that Netdata Cloud receives metric samples only when a user is accessing a dashboard and the samples transferred are usually aggregations to allow rendering the dashboards.
|
||||
|
|
|
@ -16,11 +16,11 @@ With default settings on Children, CPU utilization typically falls within the ra
|
|||
|
||||
For Netdata Parents (Metrics Centralization Points), we estimate the following CPU utilization:
|
||||
|
||||
| Feature | Depends On | Expected Utilization (CPU cores per million) | Key Reasons |
|
||||
|:--------------------:|:---------------------------------------------------:|:----------------------------------------------------------------:|:------------------------------------------------------------------------:|
|
||||
| Metrics Ingest | Number of samples received per second | 2 | Decompress and decode received messages, update database |
|
||||
| Metrics re-streaming | Number of samples resent per second | 2 | Encode and compress messages towards another Parent |
|
||||
| Machine Learning | Number of unique time-series concurrently collected | 2 | Train machine learning models, query existing models to detect anomalies |
|
||||
| Feature | Depends On | Expected Utilization (CPU cores per million) | Key Reasons |
|
||||
|:--------------------:|:---------------------------------------------------:|:--------------------------------------------:|:------------------------------------------------------------------------:|
|
||||
| Metrics Ingest | Number of samples received per second | 2 | Decompress and decode received messages, update database |
|
||||
| Metrics re-streaming | Number of samples resent per second | 2 | Encode and compress messages towards another Parent |
|
||||
| Machine Learning | Number of unique time-series concurrently collected | 2 | Train machine learning models, query existing models to detect anomalies |
|
||||
|
||||
To ensure optimal performance, keep total CPU utilization below 60% when the Parent is actively processing metrics, training models, and running health checks.
|
||||
|
||||
|
|
|
@ -12,7 +12,7 @@ Netdata offers two database modes to suit your needs for performance and data pe
|
|||
## `dbengine`
|
||||
|
||||
Netdata's `dbengine` mode efficiently stores data on disk using compression. The actual disk space used depends on how well the data compresses.
|
||||
This mode utilizes a tiered storage approach: data is saved in multiple tiers on disk. Each tier retains data at a different resolution (detail level). Higher tiers store a down-sampled (less detailed) version of the data found in lower tiers.
|
||||
This mode uses a tiered storage approach: data is saved in multiple tiers on disk. Each tier retains data at a different resolution (detail level). Higher tiers store a down-sampled (less detailed) version of the data found in lower tiers.
|
||||
|
||||
```mermaid
|
||||
gantt
|
||||
|
@ -25,7 +25,7 @@ gantt
|
|||
tier2, 365d :a3, 2023-11-02, 59d
|
||||
```
|
||||
|
||||
`dbengine` supports up to 5 tiers. By default, 3 tiers are used:
|
||||
`dbengine` supports up to five tiers. By default, three tiers are used:
|
||||
|
||||
| Tier | Resolution | Uncompressed Sample Size | Usually On Disk |
|
||||
|:-------:|:--------------------------------------------------------------------------------------------:|:------------------------:|:---------------:|
|
||||
|
@ -40,11 +40,11 @@ gantt
|
|||
|
||||
## `ram`
|
||||
|
||||
`ram` mode can help when Netdata should not introduce any disk I/O at all. In both of these modes, metric samples exist only in memory, and only while they are collected.
|
||||
`ram` mode can help when Netdata shouldn’t introduce any disk I/O at all. In both of these modes, metric samples exist only in memory, and only while they’re collected.
|
||||
|
||||
When Netdata is configured to stream its metrics to a Metrics Observability Centralization Point (a Netdata Parent), metric samples are forwarded in real-time to that Netdata Parent. The ring buffers available in these modes is used to cache the collected samples for some time, in case there are network issues, or the Netdata Parent is restarted for maintenance.
|
||||
When Netdata is configured to stream its metrics to a Metrics Observability Centralization Point (a Netdata Parent), metric samples are forwarded in real-time to that Netdata Parent. The ring buffers available in these modes are used to cache the collected samples for some time, in case there are network issues, or the Netdata Parent is restarted for maintenance.
|
||||
|
||||
The memory required per sample in these modes, is 4 bytes: `ram` mode uses `mmap()` behind the scene, and can be incremented in steps of 1024 samples (4KiB). Mode `ram` allows the use of the Linux kernel memory dedupper (Kernel-Same-Page or KSM) to deduplicate Netdata ring buffers and save memory.
|
||||
The memory required per sample in these modes, is four bytes: `ram` mode uses `mmap()` behind the scene, and can be incremented in steps of 1024 samples (4KiB). Mode `ram` allows the use of the Linux kernel memory dedupper (Kernel-Same-Page or KSM) to deduplicate Netdata ring buffers and save memory.
|
||||
|
||||
**Configuring ram mode and retention**:
|
||||
|
||||
|
|
|
@ -8,7 +8,7 @@ Netdata supports memory ballooning and automatically sizes and limits the memory
|
|||
|
||||
With default settings, Netdata should run with 100MB to 200MB of RAM, depending on the number of metrics being collected.
|
||||
|
||||
This number can be lowered by limiting the number of database tier or switching database modes. For more information check [Disk Requirements and Retention](/docs/netdata-agent/sizing-netdata-agents/disk-requirements-and-retention.md).
|
||||
This number can be lowered by limiting the number of database tier or switching database modes. For more information, check [Disk Requirements and Retention](/docs/netdata-agent/sizing-netdata-agents/disk-requirements-and-retention.md).
|
||||
|
||||
## On Metrics Centralization Points, Netdata Parents
|
||||
|
||||
|
@ -20,7 +20,7 @@ memory = UNIQUE_METRICS x 16KiB + CONFIGURED_CACHES
|
|||
|
||||
The default `CONFIGURED_CACHES` is 32MiB.
|
||||
|
||||
For 1 million concurrently collected time-series (independently of their data collection frequency), the memory required is:
|
||||
For one million concurrently collected time-series (independently of their data collection frequency), the memory required is:
|
||||
|
||||
```text
|
||||
UNIQUE_METRICS = 1000000
|
||||
|
@ -32,16 +32,16 @@ CONFIGURED_CACHES = 32MiB
|
|||
about 16 GiB
|
||||
```
|
||||
|
||||
There are 2 cache sizes that can be configured in `netdata.conf`:
|
||||
There are two cache sizes that can be configured in `netdata.conf`:
|
||||
|
||||
1. `[db].dbengine page cache size`: this is the main cache that keeps metrics data into memory. When data are not found in it, the extent cache is consulted, and if not found in that either, they are loaded from disk.
|
||||
2. `[db].dbengine extent cache size`: this is the compressed extent cache. It keeps in memory compressed data blocks, as they appear on disk, to avoid reading them again. Data found in the extend cache but not in the main cache have to be uncompressed to be queried.
|
||||
1. `[db].dbengine page cache size`: this is the main cache that keeps metrics data into memory. When data is not found in it, the extent cache is consulted, and if not found in that too, they are loaded from the disk.
|
||||
2. `[db].dbengine extent cache size`: this is the compressed extent cache. It keeps in memory compressed data blocks, as they appear on disk, to avoid reading them again. Data found in the extent cache but not in the main cache have to be uncompressed to be queried.
|
||||
|
||||
Both of them are dynamically adjusted to use some of the total memory computed above. The configuration in `netdata.conf` allows providing additional memory to them, increasing their caching efficiency.
|
||||
|
||||
## I have a Netdata Parent that is also a systemd-journal logs centralization point, what should I know?
|
||||
|
||||
Logs usually require significantly more disk space and I/O bandwidth than metrics. For optimal performance we recommend to store metrics and logs on separate, independent disks.
|
||||
Logs usually require significantly more disk space and I/O bandwidth than metrics. For optimal performance, we recommend to store metrics and logs on separate, independent disks.
|
||||
|
||||
Netdata uses direct-I/O for its database, so that it does not pollute the system caches with its own data. We want Netdata to be a nice citizen when it runs side-by-side with production applications, so this was required to guarantee that Netdata does not affect the operation of databases or other sensitive applications running on the same servers.
|
||||
|
||||
|
@ -49,9 +49,9 @@ To optimize disk I/O, Netdata maintains its own private caches. The default sett
|
|||
|
||||
`systemd-journal` on the other hand, relies on operating system caches for improving the query performance of logs. When the system lacks free memory, querying logs leads to increased disk I/O.
|
||||
|
||||
If you are experiencing slow responses and increased disk reads when metrics queries run, we suggest to dedicate some more RAM to Netdata.
|
||||
If you are experiencing slow responses and increased disk reads when metrics queries run, we suggest dedicating some more RAM to Netdata.
|
||||
|
||||
We frequently see that the following strategy gives best results:
|
||||
We frequently see that the following strategy gives the best results:
|
||||
|
||||
1. Start the Netdata Parent, send all the load you expect it to have and let it stabilize for a few hours. Netdata will now use the minimum memory it believes is required for smooth operation.
|
||||
2. Check the available system memory.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue