Page MenuHomeFreeBSD

unix: Increase the default datagram recv buffer size
ClosedPublic

Authored by markj on Dec 10 2021, 9:25 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Oct 23, 3:50 AM
Unknown Object (File)
Sun, Oct 20, 11:19 PM
Unknown Object (File)
Sep 28 2024, 7:29 PM
Unknown Object (File)
Sep 22 2024, 10:34 AM
Unknown Object (File)
Sep 22 2024, 8:52 AM
Unknown Object (File)
Sep 22 2024, 2:56 AM
Unknown Object (File)
Sep 21 2024, 3:09 PM
Unknown Object (File)
Sep 21 2024, 1:05 AM

Details

Summary

syslog(3) was recently change to support larger messages, up to 8KB.
Our syslogd handles this fine, as it adjusts /dev/log's recv buffer to a
large size. rsyslog, however, uses the system default of 4KB. This
leads to problems since our syslog(3) retries indefinitely when a send()
returns ENOBUFS, but if the message is large enough this will never
succeed. On e.g., Linux, this isn't a problem since their default
buffer sizes are quite a bit larger (seems to be ~256KB).

Increase the default recv buffer size for datagram sockets to support
8KB syslog messages without requiring the logging daemon to adjust its
buffers. This brings us in line with OpenBSD, which recently made a
similar change.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

markj requested review of this revision.Dec 10 2021, 9:25 PM

Q: Speaking of 256k - do we want to create different defaults for low-memory and high-memory systems?

I'm not sure the comment is accurate, but the change is good.

This revision is now accepted and ready to land.Dec 10 2021, 9:36 PM

Make the comment more helpful

This revision now requires review to proceed.Dec 10 2021, 9:48 PM

Note that 8KB of buffer space is not enough to support 8KB syslog messages, since dgram messages include some fixed amount of metadata that is counted against the buffer limit.

Q: Speaking of 256k - do we want to create different defaults for low-memory and high-memory systems?

I'm not sure. Do you know of any workloads where a large amount of memory is committed to unix socket buffers in steady state operation? I suspect that the main use of these limits is to ensure that an unresponsive application doesn't accumulate a huge backlog of messages in a small number of sockets, rather than ensuring that total memory usage is low. If so, then it doesn't seem terribly useful to distinguish between small and large memory systems here, but again I'm not certain.

This revision was not accepted when it landed; it landed in state Needs Review.Dec 17 2021, 6:13 PM
This revision was automatically updated to reflect the committed changes.