Add IPROTO_MSG_MAX to the config #3320
Comments
Gerold103
added a commit
that referenced
this issue
Apr 20, 2018
IProto_bind_msg is used by TX thread to udpate bind address in IProto thread with no explicit locking anything. In #3320 new IProto dynamic configuration parameter appears - 'iproto_msg_max' which regulates how many IProto requests can be in fly. The idea is to reuse iproto_bind_msg for this. Part of #3320
Gerold103
added a commit
that referenced
this issue
Apr 20, 2018
IPROTO_MSG_MAX is a constant that restricts count of requests in fly. It allows to do not produce too many fibers in TX thread, that would lead to too big overhead on fibers switching, their stack storing. But some users have powerful metal on which Tarantool IPROTO_MSG_MAX constant is not serious. The patch exposes it as a configuration runtime parameter. 'iproto_msg_max' is its name. If a user sees that IProto thread is stuck due to too many requests, it can change iproto_msg_max in runtime, and IProto thread immediately starts processing pending requests. 'iproto_msg_max' can be decreased, but obviously it can not stop already runned requests, so if now in IProto thread request count is > new 'iproto_msg_max' value, then it takes some time until some requests will be finished. Closes #3320
|
@TarantoolBot document But some users have powerful metal on which 768 constant is not serious. The patch exposes it as
|
|
@Gerold103: Accept. |
Gerold103
added a commit
that referenced
this issue
Apr 23, 2018
IPROTO_MSG_MAX is a constant that restricts count of requests in fly. It allows to do not produce too many fibers in TX thread, that would lead to too big overhead on fibers switching, their stack storing. But some users have powerful metal on which Tarantool IPROTO_MSG_MAX constant is not serious. The patch exposes it as a configuration runtime parameter. 'iproto_msg_max' is its name. If a user sees that IProto thread is stuck due to too many requests, it can change iproto_msg_max in runtime, and IProto thread immediately starts processing pending requests. 'iproto_msg_max' can be decreased, but obviously it can not stop already runned requests, so if now in IProto thread request count is > new 'iproto_msg_max' value, then it takes some time until some requests will be finished. Closes #3320
Gerold103
added a commit
that referenced
this issue
Apr 23, 2018
TX fiber pool size provides fibers to execute transactions and remote requests, so it is linked with maximal remote request count, that is allowed to be altered in the previous patch. Lets do the same for fiber pool size. Follow up #3320
Gerold103
added a commit
that referenced
this issue
Apr 24, 2018
TX fiber pool size provides fibers to execute transactions and remote requests, so it is linked with maximal remote request count, that is allowed to be altered in the previous patch. Lets do the same for fiber pool size. Follow up #3320
Gerold103
added a commit
that referenced
this issue
Apr 24, 2018
IPROTO_MSG_MAX is a constant that restricts count of requests in fly. It allows to do not produce too many fibers in TX thread, that would lead to too big overhead on fibers switching, their stack storing. But some users have powerful metal on which Tarantool IPROTO_MSG_MAX constant is not serious. The patch exposes it as a configuration runtime parameter. 'iproto_msg_max' is its name. If a user sees that IProto thread is stuck due to too many requests, it can change iproto_msg_max in runtime, and IProto thread immediately starts processing pending requests. 'iproto_msg_max' can be decreased, but obviously it can not stop already runned requests, so if now in IProto thread request count is > new 'iproto_msg_max' value, then it takes some time until some requests will be finished. `iproto_msg_max` automatically increases fiber pool size, when needed. Closes #3320
Gerold103
added a commit
that referenced
this issue
May 3, 2018
IPROTO_MSG_MAX is a constant that restricts count of requests in fly. It allows to do not produce too many fibers in TX thread, that would lead to too big overhead on fibers switching, their stack storing. But some users have powerful metal on which Tarantool IPROTO_MSG_MAX constant is not serious. The patch exposes it as a configuration runtime parameter. 'iproto_msg_max' is its name. If a user sees that IProto thread is stuck due to too many requests, it can change iproto_msg_max in runtime, and IProto thread immediately starts processing pending requests. 'iproto_msg_max' can be decreased, but obviously it can not stop already runned requests, so if now in IProto thread request count is > new 'iproto_msg_max' value, then it takes some time until some requests will be finished. `iproto_msg_max` automatically increases fiber pool size, when needed. Closes #3320
Gerold103
added a commit
that referenced
this issue
May 3, 2018
IPROTO_MSG_MAX is a constant that restricts count of requests in fly. It allows to do not produce too many fibers in TX thread, that would lead to too big overhead on fibers switching, their stack storing. But some users have powerful metal on which Tarantool IPROTO_MSG_MAX constant is not serious. The patch exposes it as a configuration runtime parameter. 'iproto_msg_max' is its name. If a user sees that IProto thread is stuck due to too many requests, it can change iproto_msg_max in runtime, and IProto thread immediately starts processing pending requests. 'iproto_msg_max' can be decreased, but obviously it can not stop already runned requests, so if now in IProto thread request count is > new 'iproto_msg_max' value, then it takes some time until some requests will be finished. `iproto_msg_max` automatically increases fiber pool size, when needed. Closes #3320
Gerold103
added a commit
that referenced
this issue
May 3, 2018
IPROTO_MSG_MAX is a constant that restricts count of requests in fly. It allows to do not produce too many fibers in TX thread, that would lead to too big overhead on fibers switching, their stack storing. But some users have powerful metal on which Tarantool IPROTO_MSG_MAX constant is not serious. The patch exposes it as a configuration runtime parameter. 'net_msg_max' is its name. If a user sees that IProto thread is stuck due to too many requests, it can change iproto_msg_max in runtime, and IProto thread immediately starts processing pending requests. 'net_msg_max' can be decreased, but obviously it can not stop already runned requests, so if now in IProto thread request count is > new 'net_msg_max' value, then it takes some time until some requests will be finished. `net_msg_max` automatically increases fiber pool size, when needed. Closes #3320
Gerold103
added a commit
that referenced
this issue
May 4, 2018
IPROTO_MSG_MAX is a constant that restricts count of requests in fly. It allows to do not produce too many fibers in TX thread, that would lead to too big overhead on fibers switching, their stack storing. But some users have powerful metal on which Tarantool IPROTO_MSG_MAX constant is not serious. The patch exposes it as a configuration runtime parameter. 'net_msg_max' is its name. If a user sees that IProto thread is stuck due to too many requests, it can change iproto_msg_max in runtime, and IProto thread immediately starts processing pending requests. 'net_msg_max' can be decreased, but obviously it can not stop already runned requests, so if now in IProto thread request count is > new 'net_msg_max' value, then it takes some time until some requests will be finished. `net_msg_max` automatically increases fiber pool size, when needed. Closes #3320
|
@Gerold103: Accept edited. |
Gerold103
added a commit
that referenced
this issue
May 8, 2018
IPROTO_MSG_MAX is a constant that restricts count of requests in fly. It allows to do not produce too many fibers in TX thread, that would lead to too big overhead on fibers switching, their stack storing. But some users have powerful metal on which Tarantool IPROTO_MSG_MAX constant is not serious. The patch exposes it as a configuration runtime parameter. 'net_msg_max' is its name. If a user sees that IProto thread is stuck due to too many requests, it can change iproto_msg_max in runtime, and IProto thread immediately starts processing pending requests. 'net_msg_max' can be decreased, but obviously it can not stop already runned requests, so if now in IProto thread request count is > new 'net_msg_max' value, then it takes some time until some requests will be finished. `net_msg_max` automatically increases fiber pool size, when needed. Closes #3320
Gerold103
added a commit
that referenced
this issue
May 8, 2018
IPROTO_MSG_MAX is a constant that restricts count of requests in fly. It allows to do not produce too many fibers in TX thread, that would lead to too big overhead on fibers switching, their stack storing. But some users have powerful metal on which Tarantool IPROTO_MSG_MAX constant is not serious. The patch exposes it as a configuration runtime parameter. 'net_msg_max' is its name. If a user sees that IProto thread is stuck due to too many requests, it can change iproto_msg_max in runtime, and IProto thread immediately starts processing pending requests. 'net_msg_max' can be decreased, but obviously it can not stop already runned requests, so if now in IProto thread request count is > new 'net_msg_max' value, then it takes some time until some requests will be finished. `net_msg_max` automatically increases fiber pool size, when needed. Closes #3320
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When we have many (over 500) connections to the Tarantool(v1.7.6) and at a time, several requests (for ex.4) will be made to each connection, an error occurs:
2018-04-04 23:20:08.039 [18788] iproto iproto.cc:318 W> readahead limit reached, stopping input on connection fd 1517, aka 10.1.92.120:3301, peer of 10.1.90.65:22328This is bеcause the condition is satisfied:
request_count > connection_count + IPROTO_MSG_MAXhttps://github.com/tarantool/tarantool/blob/1.7/src/box/iproto.cc line 265
To manipulate the value of IPROTO_MSG_MAX, render it in a config
The text was updated successfully, but these errors were encountered: