Skip to content

account queued bytes by real message footprint, not payload length #160

Description

@fabracht

max_queued_bytes_per_client is accounted using the payload length alone, so it does not track the real memory a queued message occupies.

  • crates/mqtt5/src/broker/storage/client_queue.rs:233 and :344bytes: body.payload.len()

A QueuedMessage also owns topic, client_id, user properties, content type, response topic and correlation data, plus the struct itself, its Arc, and the queue slot. None of that is counted, so a queue reported as "within its 64 MiB budget" occupies more than 64 MiB, and the gap widens as payloads get smaller relative to per-message overhead.

Suggested change

Account an estimated true footprint (payload + topic + client_id + properties + a fixed per-entry constant) so the configured cap bounds actual memory rather than payload bytes.

Measured impact

Lower than expected, so this is filed as a configuration-accuracy improvement rather than a memory problem. Comparing 256-byte and 4096-byte payloads under the same 64 MiB budget gave comparable broker RSS (582 MB vs 502 MB), i.e. per-message overhead did not dominate in that test. The accounting is still misleading for operators sizing a broker.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions