Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docs: Update memory ballast documentation #5106

Merged
merged 10 commits into from
Jan 14, 2022
2 changes: 1 addition & 1 deletion docs/sources/configuration/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -93,7 +93,7 @@ Pass the `-config.expand-env` flag at the command line to enable this way of set
# if true. If false, the OrgID will always be set to "fake".
[auth_enabled: <boolean> | default = true]

# The amount of virtual memory to reserve as a ballast in order to optimise
# The amount of virtual memory in bytes to reserve as ballast in order to optimize
# garbage collection. Larger ballasts result in fewer garbage collection passes, reducing CPU overhead at
# the cost of heap size. The ballast will not consume physical memory, because it is never read from.
# It will, however, distort metrics, because it is counted as live memory.
Expand Down
7 changes: 4 additions & 3 deletions docs/sources/operations/scalability.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,8 @@ It is not valid to start the querier with both a configured frontend and a sched

The query scheduler process itself can be started via the `-target=query-scheduler` option of the Loki Docker image. For instance, `docker run grafana/loki:latest -config.file=/cortex/config/cortex.yaml -target=query-scheduler -server.http-listen-port=8009 -server.grpc-listen-port=9009` starts the query scheduler listening on ports `8009` and `9009`.

## Memory Ballast
In compute constrained environments, garbage collection can become a significant factor. This can be optimised, at the expense of memory consumption, by configuring a memory ballast using the `ballast_bytes` configuration option.
## Memory ballast

A larger memory ballast will mean that standard heap size volatility is less relatively significant, and therefore less likely to trigger garbage collection. This will result in lower compute overhead, but higher memory consumption, as the heap is cleaned less frequently.
In compute-constrained environments, garbage collection can become a significant performance factor. Frequently-run garbage collection interferes with running the application by using CPU resources. The use of memory ballast can mitigate the issue. Memory ballast allocates extra, but unused virtual memory in order to inflate the quantity of live heap space. Garbage collection is triggered by the growth of heap space usage. The inflated quantity of heap space reduces the perceived growth, so garbage collection occurs less frequently.

Configure memory ballast using the ballast_bytes configuration option.