[luci] LuCId daemon explicit garbage collection

[Bryan Mayland]

On 7/20/2011 5:13 PM, Jo-Philipp Wich wrote:
> Yes, you're right here. I think the most reasonable thing to do is 
> gc'ing before the work. I attached a patch which should implement your 
> proposal.
Continuing on with the out of memory problem.  I found that this update 
provided a massive boost in the stability of a long-running LuCId, 
however experimentation showed a constant increase in memory over time.  
Check again the kiwi-colored line which measures LUA state memory use 
over time checked right after the collectgabage("collect") call:
https://picasaweb.google.com/lh/photo/qjBlcWcdqNsoNOPZyuQd3GagQEnRdXMcytaEIVOlUv8?feat=directlink

If you connect all the points where the allocated memory increases, it 
forms a straight line of about 7KB/hour.  The load on the server was a 
looping wget process pulling a call() page every 15 seconds.  I assumed 
it was my code but I kept stripping out code straight through to lucid 
until I found it.

Turns out in lucid.lua:create_process() (238)
     tpids[pid] = waitcb or true
An entry is added to the process ID map waiting for the process to 
exit.  This entry is never removed so the tpids table grows 
continuously.  Each table entry is somewhere in the neighborhood of 20 
bytes.  The solution is simple, add a line to clear the table entry once 
the process exits around line 153
                         if tpids[pid] then
                                 tcount = tcount - 1
                                 if tpids[pid] ~= true then
                                         tpids[pid](pid, stat, code)
                                 end
                                 tpids[pid] = nil  -- new line here
                         end

I don't know if you wanted me to create a ticket for another one-line 
change or just fix it up directly.  I've now been running 8 hours and 
I'm still sitting at the same LUA state size as I started with (352KB)