You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: add memory limiter to drop data when a soft limit is reached (#1827)
## Problem
At the moment, if there is pressure in the pipeline for any reason, and
batches are failed to export, they will start building up in the queues
of the collector exporter and grow memory unboundly.
Since we don't set any memory request or limit on the node collectors
ds, they will just go on to consume more and more of the available
memory on the node:
1. Will show a pick in resource consumption on the cluster metrics.
2. Starve other pods on the same node, which now has less spare memory
to grow into.
3. If the issue is not transient, the memory will just keep increasing
over time
4. The amount of data in the retry buffers, will keep the CPU busy
attempting to retry the rejected or unsuccessful batches.
## Levels of Protections
To prevent the above issues, we imply few level of protections, listed
from first line to last resort:
1. setting GOMEMLIMIT to a (now hardcoded constant) `352MiB`. At this
point, go runtime GC should kick in and start reclaiming memory
aggressively.
2. Setting the otel collector soft limit to (now hardcoded constant)
`384MiB`. When the heap allocations reach this amount, the collector
will start dropping batches of data after they are exported from the
`batch` processor, instead of streaming them down the pipeline.
3. Setting the otel collector hard limit to `512MiB`. When the heap
reaches this number, a forced GC is performed.
4. Setting the memory request to `256MiB`. This ensures we have at least
this amount of memory to handle normal traffic and some slack for spikes
without running into OOM. the rest of the memory is consumed from
available memory on the node which by handy for more buffering, but may
also cause OOM if the node has no resources.
## Future Work
- Add configuration options to set these values, preferably as a
spectrum for trace-offs: "resource-stability", "resource-spikecapacity"
- drop the data as it received not after it is batched -
open-telemetry/opentelemetry-collector#11726
- drop data at receiver when it's implemented in collector -
open-telemetry/opentelemetry-collector#9591
// TODO: currently using hardcoded values, should be configurable.
18
+
//
19
+
// memory request is expensive on daemonsets since it will consume this memory
20
+
// on each node in the cluster. setting to 256, but allowing memory to spike higher
21
+
// to consume more available memory on the node.
22
+
// if the node has memory to spare, we can use it to buffer more data before dropping,
23
+
// but it also means that if no memory is available, collector might get killed by OOM killer.
24
+
//
25
+
// we can trade-off the memory request:
26
+
// - more memory request: more memory allocated per collector on each node, but more buffer for bursts and transient failures.
27
+
// - less memory request: efficient use of cluster resources, but data might be dropped earlier on spikes.
28
+
// currently choosing 256MiB as a balance (~200MiB left for heap to handle batches and export queues).
29
+
//
30
+
// we can trade-off how high the memory limit is set above the request:
31
+
// - limit is set to request: collector most stable (no OOM) but smaller buffer for bursts and early data drop.
32
+
// - limit is set way above request: in case of memory spike, collector will use extra memory available on the node to buffer data, but might get killed by OOM killer if this memory is not available.
33
+
// currently choosing 512MiB as a balance (200MiB guaranteed for heap, and the rest ~300MiB of buffer from node before start dropping).
34
+
//
35
+
return odigosv1.CollectorsGroupResourcesSettings{
36
+
MemoryRequestMiB: 256,
37
+
MemoryLimitMiB: 512+64,
38
+
MemoryLimiterLimitMiB: 512,
39
+
MemoryLimiterSpikeLimitMiB: 128, // meaning that collector will start dropping data at 512-128=384MiB
40
+
GomemlimitMiB: 512-128-32, // start aggressive GC 32 MiB before soft limit and dropping data
0 commit comments