Surface and bound aggregate daemon memory footprint #2

anuna-02 commented 2026年05月06日 07:45:09 +02:00

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