diff options
author | Scott Lystig Fritchie <[email protected]> | 2010-10-22 15:25:10 -0500 |
---|---|---|
committer | Rickard Green <[email protected]> | 2010-11-02 11:48:44 +0100 |
commit | 8faf1746ece60fc5fa634e5fd16e98df1ef7f3ba (patch) | |
tree | 7420747bcb3589811ec177c09f110d424312debb /README.md | |
parent | 499082d25170aa7edf922a6aee0465a7ffb144d4 (diff) | |
download | otp-8faf1746ece60fc5fa634e5fd16e98df1ef7f3ba.tar.gz otp-8faf1746ece60fc5fa634e5fd16e98df1ef7f3ba.tar.bz2 otp-8faf1746ece60fc5fa634e5fd16e98df1ef7f3ba.zip |
Add flag-based setting for the distribution buffer busy limit
Id: OTP-8912
This patch creates a new family of flags with the "+z" prefix. It
further creates a new configuration option called "dbbl" (which is the
first letter of the name dist_buf_busy_limit). Example usage of this
flag would be "+zdbbl 1048576".
This patch creates an adjustable buffer limit for the amount of data
that may be buffered by the erlang distribution code (in dist.c
specifically). Before this patch, this hard-coded constant was used:
#define ERTS_DE_BUSY_LIMIT (128*1024)
When large binaries are transmitted between nodes (or simply a lot of
medium-sized binaries), it is very easy to hit the old 128KB limit.
Processes that use the erlang:system_monitor() BIF to monitor system
events can be spammed by {monitor, busy_dist_port, ...} message tuples
at rates of tens to even hundreds of messages/second.
A larger buffer limit will allow processes to buffer more outgoing
messages over the distribution. When the buffer limit has been
reached, sending processes will be suspended until the buffer size has
shrunk. The buffer limit is per distribution channel. A higher limit
will give lower latency and higher throughput at the expense of
higher memory usage.
A variation of this patch has been in commercial production use in at
least two companies that the author is aware of. Larger buffer values
can reduce the number of {monitor, busy_dist_port, ...} system
messages drastically, lower overall messaging latencies, and prevent
false timeouts and 'nodedown' messages in extremely busy Mnesia systems.
Test suite: there are two tests:
a. In erlexec_SUITE.erl to test basic set & get of the value
b. In distribution_SUITE.erl, to verify that setting +zdbbl very
low will actually change behavior.
Diffstat (limited to 'README.md')
0 files changed, 0 insertions, 0 deletions