iproto: allow to configure IPROTO_MSG_MAX
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
Showing
- src/box/box.cc 13 additions, 1 deletionsrc/box/box.cc
- src/box/box.h 1 addition, 0 deletionssrc/box/box.h
- src/box/iproto.cc 85 additions, 37 deletionssrc/box/iproto.cc
- src/box/iproto.h 20 additions, 0 deletionssrc/box/iproto.h
- src/box/lua/cfg.cc 12 additions, 0 deletionssrc/box/lua/cfg.cc
- src/box/lua/load_cfg.lua 3 additions, 0 deletionssrc/box/lua/load_cfg.lua
- src/fiber_pool.c 6 additions, 0 deletionssrc/fiber_pool.c
- src/fiber_pool.h 10 additions, 1 deletionsrc/fiber_pool.h
- test/app-tap/init_script.result 28 additions, 27 deletionstest/app-tap/init_script.result
- test/box/admin.result 2 additions, 0 deletionstest/box/admin.result
- test/box/cfg.result 27 additions, 0 deletionstest/box/cfg.result
- test/box/cfg.test.lua 10 additions, 0 deletionstest/box/cfg.test.lua
- test/box/net_msg_max.result 127 additions, 2 deletionstest/box/net_msg_max.result
- test/box/net_msg_max.test.lua 63 additions, 2 deletionstest/box/net_msg_max.test.lua
Loading
Please register or sign in to comment