[luci] Lua memory usage

Jo-Philipp Wich xm at subsignal.org
Wed Nov 28 15:21:04 CET 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey.

> I'm running the lua intrepreter in the uhttpd process. I have
> adjusted the original lua plugin to not fork. This gives a good
> improvement to initial page appearance time. It does not change the
> actual page production time. It is a trade-off of memory for
> response time.

Maybe we can make it configurable in the existing plugin, then you can
reuse the same codebase.

> But I started seeing the uhttpd memory rising too much. I added a
> lua garbage collection call after each request which made an
> obvious improvement.

This as well.

> But there was still a real leak. I looked at the lua heap info and 
> tracked it to
> 
> +--- a/libs/web/luasrc/dispatcher.lua ++++
> b/libs/web/luasrc/dispatcher.lua +@@ -435,7 +435,7 @@ function
> dispatch(request) + + 	if type(target) == "function" then +
> util.copcall(function() +-			local oldenv = getfenv(target) ++
> local oldenv = getfenv() + 			local module = require(c.module) +
> local env = setmetatable({}, {__index=
> 
> 'target' in my case, has history. This code would build up a chain
> of tables for env.
> 
> I'm still not 100% sure this fix is correct. I don't fully
> understand which elements of env are important for the target
> functions, beyond the standard environment. My testing has not
> found a problem, yet.

That code is there to preserve the original environment of the
referenced functions, e.g. if they want to access stuff declared in
the module they're originating from.

I think the change above would break at least
http://luci.subsignal.org/trac/browser/luci/trunk/applications/luci-commands/luasrc/controller/commands.lua#L168
- - maybe you can test it, I believe it will fail to find the local
parse_cmdline() function.

Not sure how to fix that properly, maybe by moving the metatable
binding inside the call() function somehow.

> But, there was still a leak, visible in the uclibc heap, not the
> lua memory report. Playing with the uclibc malloc_trim, and also
> restarting the lua interpreter did not help. I have resorted to
> re-starting the uhttpd process.

The leak could happen inside lmo.so or parser.so, maybe take a closer
look there.

> I suspect the process memory is getting fragmented, so that a
> better allocator is the solution. Lua provides a hook for a custom
> allocator.
> 
> Thoughts?

Uhm, no, not at the moment but I would be interested in your findings
in case you try it with another allocator.


~ Jow
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlC2Hc0ACgkQdputYINPTPOumgCdFxf8p23JlDzDhvX5nA6iThyA
RN0An2K9im/Mzd5n3x4AP2B2NAP9NIAF
=YI/V
-----END PGP SIGNATURE-----


More information about the luci mailing list