From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng1.m.smailru.net (smtpng1.m.smailru.net [94.100.181.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 7157B42EF5C for ; Fri, 19 Jun 2020 23:59:32 +0300 (MSK) From: Igor Munkin Date: Fri, 19 Jun 2020 23:50:22 +0300 Message-Id: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [Tarantool-patches] [PATCH 0/2] Reduce Lua GC pressure in Tarantool List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy , Sergey Ostanevich Cc: tarantool-patches@dev.tarantool.org This series consists of the two patches that seems unrelated. However you can look at the CI results[1] for the first incarnation[2] and see the reason why the test is also attached. The first patch just makes the flaky box-tap/key_def.test.lua stable and thereby fixes #4252[3]. The fix is quite simple: since it hits the known LuaJIT problem[4] disabling JIT for particular Lua Fun methods is a solution for now. When the JIT misbehave is fixed, the patch can be reverted. Furthermore, Sasha Tu. asked to open another ticket in our queue tracking the origin LuaJIT issue, since #4252 will be closed. I failed to find the exact way the patch affects this test, but again, the result is in the CI. The second patch was born in scope of Sasha L. research[5]. I glanced on the flamegraphs and then to the sources and saw no reason why the same functions need to be created on each iproto CALL/EVAL or "stored" procedure call. These GCfunc objects live only in scope of the coroutine (i.e. fiber) serving a request, but can be reused for the others since there are no upvalues depending on the request context. As a result of the change GC pressure is reduced. Vlad asked me personally to make and provide some benchmarks for the changes. I made the one you can find here[6]. One need to start instance and run several times with the same Tarantool binary. After 15 runs with default args I obtained the following results: * Vanilla bleeding master (mean): | ===== 2.5.0-147-ge7a70be4e ===== | call by ref GC: 953127 Kb | call by ref time: 1.401803 sec | call GC: 507813 Kb | eval GC: 686523 Kb * Patched bleeding master (mean): | ===== 2.5.0-149-g71b2bbc8a ===== | call by ref GC: 921877 Kb | call by ref time: 1.318509 sec | call GC: 476563 Kb | eval GC: 655273 Kb * Relative measurements (before -> after): | call by ref GC: -3% (-31250 Kb) | call by ref time: -5% (-0.083294 sec) | call GC: -6% (-31250 Kb) | eval GC: -4% (-31250 Kb) Even if one consider benchmarks a bit synthetic, this change improves platform performance a priori: as a result less garbage is produced, ergo GC machinery is triggered less often. Branch: https://github.com/tarantool/tarantool/tree/imun/experimental-execute-lua-handlers I guess a ChangeLog entry is irrelevant, since nothing is changed for the user space. Igor Munkin (2): test: disable JIT for Lua Fun totable function box: reduce box_process_lua Lua GC memory usage src/box/lua/call.c | 32 +++++++++++++++++++++++++++----- test/box-tap/key_def.test.lua | 8 ++++++++ 2 files changed, 35 insertions(+), 5 deletions(-) [1]: https://gitlab.com/tarantool/tarantool/-/pipelines/138781540/builds [2]: https://github.com/tarantool/tarantool/commit/8fe7f00 [3]: https://github.com/tarantool/tarantool/issues/4252 [4]: https://github.com/LuaJIT/LuaJIT/issues/584 [5]: https://github.com/tarantool/vshard/issues/224 [6]: https://gist.github.com/igormunkin/c941074fa9fdf0f7a4f068498fb5e24c -- 2.25.0