anuna-research/hark
1
0
Fork 0
Code Issues 3 Pull requests 1 Projects Packages Wiki Activity Actions

Surface and bound aggregate daemon memory footprint #2

New issue
Open
opened 2026-05-06 05:45:09 +00:00 by anuna-02 · 0 comments
anuna-02 commented 2026-05-06 05:45:09 +00:00 (Migrated from codeberg.org)
Copy link

Context

Per-handle resource limits exist (max_messages_per_handle, max_bytes_per_handle) but the product max_bytes_per_handle × concurrent_handles is the daemon's worst-case inbound-queue memory ceiling. Today this product is unbounded because the handle count is unbounded (see #1).

Once #1 lands, the worst-case ceiling becomes max_bytes_per_handle × max_handles. With current defaults that is 64 MiB × 64 = 4 GiB of inbound queue per daemon — already large enough to surprise an operator who picked the defaults without thinking about the multiplication.

Proposed change

  1. Compute the effective ceiling at startup and emit a structured log line: daemon.queue_ceiling_bytes = X (max_bytes_per_handle=Y × max_handles=Z).
  2. Show the same value in daemon status.
  3. Add daemon.queue_ceiling_warn_bytes config; warn at startup if the computed ceiling exceeds it. Suggest default 1 GiB.
  4. Document the multiplication in README config notes; show the aggregate before the per-handle figures.

This is awareness, not enforcement. The hard cap remains max_bytes_per_handle; this issue surfaces the consequence of the multiplication.

Acceptance

  • daemon status shows aggregate ceiling.
  • Startup log includes the computation.
  • Warning logged when ceiling > queue_ceiling_warn_bytes.
  • README config section explains the multiplication.

Refs

  • Depends on #1
  • cbcl-runtime deck slide 17
## Context Per-handle resource limits exist (`max_messages_per_handle`, `max_bytes_per_handle`) but the product `max_bytes_per_handle × concurrent_handles` is the daemon's worst-case inbound-queue memory ceiling. Today this product is unbounded because the handle count is unbounded (see #1). Once #1 lands, the worst-case ceiling becomes `max_bytes_per_handle × max_handles`. With current defaults that is `64 MiB × 64 = 4 GiB` of inbound queue per daemon — already large enough to surprise an operator who picked the defaults without thinking about the multiplication. ## Proposed change 1. Compute the effective ceiling at startup and emit a structured log line: `daemon.queue_ceiling_bytes = X (max_bytes_per_handle=Y × max_handles=Z)`. 2. Show the same value in `daemon status`. 3. Add `daemon.queue_ceiling_warn_bytes` config; warn at startup if the computed ceiling exceeds it. Suggest default 1 GiB. 4. Document the multiplication in README config notes; show the aggregate before the per-handle figures. This is awareness, not enforcement. The hard cap remains `max_bytes_per_handle`; this issue surfaces the consequence of the multiplication. ## Acceptance - [ ] `daemon status` shows aggregate ceiling. - [ ] Startup log includes the computation. - [ ] Warning logged when ceiling > `queue_ceiling_warn_bytes`. - [ ] README config section explains the multiplication. ## Refs - Depends on #1 - `cbcl-runtime` deck slide 17
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
feat/auto-reconnect
fix/clippy-1.95-release-gate
chore/release-woodpecker
fix/spec-013-ib3-keyready-announce
docs/spec-013-cbcl-bus-interop
feat/spec-016-onboarding-dx
feat/impl-013-mls
v0.1.2
v0.1.1
v0.1.0
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
anuna-research/hark#2
No description provided.