dao-jun commented on PR #23165:
URL: https://github.com/apache/pulsar/pull/23165#issuecomment-2286885362
> Just curious to know when it would be useful to tune this value for
Pulsar. What is the purpose and background of this PR, is there a real reason
behind this?
The TCP backlog parameter is an OS-level configuration, if Pulsar doesn't
set it, it will use OS config.
When many connections are trying to connect to the broker, some of them can
be rejected by the TCP protocol.
Since it is an OS-level config, it's not easy to locate the problem if this
situation happens.
We ran into this problem in our customer's Pulsar cluster, their SO_BACKLOG
was set to 128 on their OS, and we found many producers/consumers failed to
connect to the broker(they have more than 50k consumers on 3 brokers). After
analyzing the TCP packets, we found the problem.
I wanted to hard-code the SO_BACKLOG to 1024, but a configuration item may
be better.
And if we explicitly declare this in Pulsar instead of using the SO_BACKLOG
value which configured in `/proc/sys/net/core/somaxconn` file, it could more
easier to locate the problem when we run into the same problem.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
