Large number of ephemeral consumers could exhaust Go runtime's max OS threads. #2764
Conversation
| func init() { | ||
| // Minimum for blocking disk IO calls. | ||
| const minNIO = 4 | ||
| nIO := runtime.GOMAXPROCS(0) |
There was a problem hiding this comment.
I think we recommend a value of around 4 for this dont we? Is that really enough under heavy load?
I am not sure how the raft layer behaves exactly but this will presumably not slow down handling of the general keep alive of raft membership right? But could slow down significantly committing data there I presume. Would that increase leader elections under very stressed situations?
There was a problem hiding this comment.
This is usually set to num cores/cpus, so on my machine its 20 (hyper-threads), but on smaller machines we can use up to 4 instead of setting to 1 or 2. I played with increasing this in some tests but makes no difference since the machine can only be really doing N things in parallel.
This is only effecting the consumer stores, not stream stores which is what is used for nrg/raft layer.
Under a loaded test I had yesterday, performance was much better when lots of ephemeral consumers were trying to do those things all at the same time, and of course the crazy number of threads took its toll on the OS. Did both darwin and linux, so feel pretty good after spending yesterday on it perf wise.
There was a problem hiding this comment.
Yes, I know defaults but we often say nats server works best on 4ish cores and recommend setting this to 4, was thinking about that
derekcollison
force-pushed
the
issue-2742
branch
from
1918a66
to
c1f83fa
Compare
…er would exhaust the OS thread limit - default 10k. Under certain situations large number of consumers that are racing to update state or delete their stores during a delete would start taking up OS threads due to blocking disk IO. When this happened and their were a bunch of Go routines becoming runnable the Go runtime would create extra OS threads to fill in the runnable pool and would exhaust the max thread setting. This code places a channel as a simple semaphore to limit the number of disk IO blocking OS threads. Signed-off-by: Derek Collison <derek@nats.io>
derekcollison
force-pushed
the
issue-2742
branch
from
c1f83fa
to
c5fbb63
Compare
Under certain situations large number of consumers that are racing to update state or delete their stores during a delete
would start taking up OS threads due to blocking disk IO. When this happened and their were a bunch of Go routines becoming runnable the Go runtime would create extra OS threads to fill in the runnable pool and would exhaust the max thread setting. Even if it did not exhaust it you could see a quick run up in memory and unstable systems.
This code places a channel as a simple semaphore to limit the number of disk IO blocking OS threads.
Signed-off-by: Derek Collison derek@nats.io
Resolves #2742
/cc @nats-io/core