Hi Thierry,
On Thu, Jan 09, 2020 at 10:34:35AM +0100, Thierry Fournier wrote:
> I'm remember: the execution of the GC were the only way to close TCP
> connexions
> because in some cases the object provided by core.tcp() is not closed and the
> connexion is not released. Without the GC execution, HAProxy reach the maximum
> of available connexion, and the process were blocked. The flag forcing the GCC
> is set only is we use a socket.
Ah OK then it makes sense, thanks for the explanation. However I'm seeing
that the GC is forced for every yield/resume call, and not just on destroy.
Maybe it could be acceptable not to call it on resume ?
Sada, would you be interested in checking if this solves most of the
performance issue:
diff --git a/src/hlua.c b/src/hlua.c
index 37f7866874..e5257efb54 100644
--- a/src/hlua.c
+++ b/src/hlua.c
@@ -1195,7 +1195,7 @@ resume_execution:
}
/* This GC permits to destroy some object when a Lua timeout strikes. */
- if (lua->flags & HLUA_MUST_GC &&
+ if (0 && lua->flags & HLUA_MUST_GC &&
ret != HLUA_E_AGAIN)
lua_gc(lua->T, LUA_GCCOLLECT, 0);
> Maybe we try to include new option "tune.lua.forced-gc".
Based on your description if we need an option, I'd rather have the
opposite, like "tune.lua.disable-gc" so that it remains enabled by
default, and with an explanation that one must not disable it.
Thanks,
Willy
