(2.12) Raise max_buffered_msgs defaults by 10x#6633
Conversation
neilalexander
left a comment
neilalexander
left a comment
There was a problem hiding this comment.
In principle I think this is OK, as we discussed last week, but I think it needs some kind of test to prove that the server copes and there aren't secondary effects.
Maybe copy TestJetStreamRateLimitHighStreamIngest into a new long-running test to prove it?
|
Do we want to consider this for 2.12 or shall we close for now? |
|
Should have been for v2.11 I think... we can close for now and revisit when needed. |
|
What is the status of this? |
|
These defaults have been working better in scale tests without the servers struggling much and fixed issues in larger deployments with >100K connections. Reopened to see if we can try to change defaults for v2.12. |
|
Wondering if there's a fairer balance somewhere for defaults, i.e. increasing the default msgs to 100,000 from 10,000. That way messages over 1KB would be more likely to hit the max size limit (if left at 128MB) and messages under 1KB would be more likely to hit the max messages limit. Also keep in mind with the bump to 256MB that this is per stream, not server-wide, so I'm a bit less comfortable with increasing that too much. 128MB should be more than fair. |
wallyqs
changed the title
This will avoid running into IPQ len on simple benchmarks or use cases that the server handles fine, the max_buffered_msgs is enough to protect the memory usage in most cases. Signed-off-by: Waldemar Quevedo <wally@nats.io>
wallyqs
force-pushed
the
max-msgs-limits
branch
from
a0caae5 to
13ceddf
Compare
wallyqs
changed the title
MauriceVanVeen
changed the title
2 participants
Signed-off-by: Waldemar Quevedo wally@nats.io