Skip to content

Add runtime memory protection settings to Nitro memory management docs#3155

Open
a-thomas-22 wants to merge 15 commits intomasterfrom
at/affectionate-mahavira
Open

Add runtime memory protection settings to Nitro memory management docs#3155
a-thomas-22 wants to merge 15 commits intomasterfrom
at/affectionate-mahavira

Conversation

@a-thomas-22
Copy link
Copy Markdown
Contributor

@a-thomas-22 a-thomas-22 commented Mar 14, 2026

Summary

  • Documents node.resource-mgmt.mem-free-limit (RPC throttling via HTTP 429) and node.block-validator.memory-free-limit (validation pausing) as a new "Runtime memory protection" section
  • Explains the shared cgroup-based memory checking mechanism (v1/v2), including the formula for effective usage calculation
  • Lists all Prometheus metrics and log lines emitted by both features
  • Adds guidance on choosing between the two settings based on node type
  • Adds two new tuning recommendations for monitoring these protections

Ref: SREP-2531

Document node.resource-mgmt.mem-free-limit (RPC throttling) and
node.block-validator.memory-free-limit (validation pausing), including
how cgroup-based memory checking works, metrics emitted, log lines,
and guidance on choosing between the two settings.
@vercel
Copy link
Copy Markdown

vercel bot commented Mar 14, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
arbitrum-docs Ready Ready Preview Mar 26, 2026 2:06am

Request Review

Delete the "Choosing between the two settings" subsection and its table that compared node.resource-mgmt.mem-free-limit and node.block-validator.memory-free-limit. Cleans up the Nitro memory management docs by removing the redundant/outdated comparison.
@a-thomas-22 a-thomas-22 marked this pull request as ready for review March 19, 2026 07:28
| **glibc malloc arenas** | Per-thread arena overhead for CGO allocations | No | `MALLOC_ARENA_MAX` |

Only the Go heap is subject to Go's garbage collector and `GOMEMLIMIT`. The CGO and `mmap` allocations are invisible to Go's runtime. They don't appear in `runtime.MemStats` or standard Go memory profiles, but they still consume container memory and count toward your memory limit.
Only the Go heap is subject to Go's garbage collector and `GOMEMLIMIT`. The CGO and `mmap` allocations are invisible to Go's runtime. They don't appear in `runtime.MemStats` or standard Go memory profiles, but they still consume er memory and count toward your memory limit.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is "consume er memory" correct?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants