Skip to content

Logmsg memory allocation#891

Merged
sodomelle merged 7 commits intoaxoflow:mainfrom
bazsi:logmsg-memory-allocation
Jan 30, 2026
Merged

Logmsg memory allocation#891
sodomelle merged 7 commits intoaxoflow:mainfrom
bazsi:logmsg-memory-allocation

Conversation

@bazsi
Copy link
Member

@bazsi bazsi commented Dec 21, 2025

This PR improves the memory used by LogMessage in a number of ways, as 1M messages can consume surprisingly large amount of RAM today.

Storing 1M messages in a memory queue with the patch:

  • RSS as reported by the kernel: 7,261,610kB
  • memory used as reported by syslog-ng: 6,331,651kB

Without the patch (but with my memory accounting fixes), same 1M messages:

  • RSS as reported by the kernel: 15,149,480kB
  • memory used as reported by syslog-ng: 8,499,719kB

Interestingly, the performance even improved with the patched version, even though it is doing an extra realloc. (29.592s vs 28.377s), but I'd need to rerun my tests.

Patched metrics, 6483 bytes per message on average, containing both a JSON text (2kB) and a flattened version of the JSON

syslogng_memory_queue_memory_usage_bytes{filename="/dev/null",driver="file",id="#anon-destination0#0"} 6483610960
syslogng_memory_queue_capacity{filename="/dev/null",driver="file",id="#anon-destination0#0"} 10000
syslogng_memory_queue_events{filename="/dev/null",driver="file",id="#anon-destination0#0"} 999940
syslogng_memory_queue_processed_events_total{filename="/dev/null",driver="file",id="#anon-destination0#0"} 1000000

@orymate

@bazsi bazsi force-pushed the logmsg-memory-allocation branch 7 times, most recently from 64b0c97 to 8cda489 Compare December 23, 2025 20:52
@bazsi bazsi force-pushed the logmsg-memory-allocation branch 2 times, most recently from c3362cc to cd4ef81 Compare January 24, 2026 14:50
@bazsi bazsi changed the title RFC: Logmsg memory allocation Logmsg memory allocation Jan 24, 2026
@bazsi
Copy link
Member Author

bazsi commented Jan 24, 2026

I decided to split off the controversial part of this PR into a separate branch (which shrinks the message payload when adding to the queue), so this one should be easier/simpler to review/merge.

@OverOrion OverOrion requested review from OverOrion and sodomelle and removed request for OverOrion January 27, 2026 13:38
@bazsi bazsi force-pushed the logmsg-memory-allocation branch from cd4ef81 to 9cf36d1 Compare January 28, 2026 21:54
bazsi added 7 commits January 30, 2026 09:03
This functionality is going to be refactored into a more elaborate algorithm
to resize an NVTable, assuming a new storage needed.  To be used both from
nv_table_clone() and nv_table_resize(), in a next patch.

Signed-off-by: Balazs Scheidler <[email protected]>
Whenever NVTable needs to grow (either during clone or realloc), the new
nv_table_get_next_size() function calculates the right new size, while
ensuring some "additional_space" becomes available in the new clone.

Previously, we always erred on the side of increasing the allocation size,
so that any expected new changes would not need another bump of the size.
This algorithm however, can waste a lot of memory.

The new algorithm is:
  * increase at least 256 bytes,
  * only increase the size if the current allocation does not fit
  * use 4k aligned sizes for large NVTables (>4kB) or 1k for small ones

We might have slightly more reallocs this way, but the total allocation of a
LogMessage should be a lot less.

Signed-off-by: Balazs Scheidler <[email protected]>
…() function

We do not support cases where these would point to different instances, so
reduce redundancy by using a single in/out pointer.

Signed-off-by: Balazs Scheidler <[email protected]>
In case our "payload" would be larger than 2kB, do not piggy back the
payload at the end of the LogMessage.

Signed-off-by: Balazs Scheidler <[email protected]>
Signed-off-by: Balazs Scheidler <[email protected]>
@bazsi bazsi force-pushed the logmsg-memory-allocation branch from 9cf36d1 to da206c0 Compare January 30, 2026 08:03
@sodomelle sodomelle merged commit 24a361b into axoflow:main Jan 30, 2026
22 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants