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 B8CC642EF5C for ; Wed, 24 Jun 2020 01:08:35 +0300 (MSK) Date: Wed, 24 Jun 2020 00:59:23 +0300 From: Igor Munkin Message-ID: <20200623215923.GK3503@tarantool.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Subject: Re: [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: Kirill Yukhin Cc: tarantool-patches@dev.tarantool.org, Vladislav Shpilevoy Kirill, Please proceed with the series. On 19.06.20, Igor Munkin wrote: > 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 > -- Best regards, IM