shaping.lua: explicit gc in kumo.tsa.config.monitor

The config monitor task is a long-lived task that runs
inside the same lua context for its entire lifetime.

That task obtains a reference to the current shaping data
every 30 seconds to decide whether it needs to synthesize
an update to the config epoch.

Lua's memory management cannot see the total amount of
ram consumed by the shaping data because the shaping data
is a userdata type whose ram is managed externally.
That means that lua things that this task is generally not
using many resources (~ a handful of pointers per loop iteration)
and gc doesn't kick in very aggressively.

For sites with large TSA shaping overrides, or otherwise with
very large shaping data, this can result in an accumulation
of stale shaping data in that long-lived lua context.

This commit adds an explicit gc trigger before the task
sleeps on each iteration so that we can release those references.
This commit is contained in:
Wez Furlong
2024-12-13 06:38:34 -07:00
parent 77832e81a6
commit b3aa6d4154
+12
View File
@@ -239,6 +239,18 @@ kumo.on('kumo.tsa.config.monitor', function(args)
if not status then
print('TSA Error, will retry in 30 seconds', status, err)
end
-- load_shaping_data is a memoized function that will return
-- a cached reference to the shaping data, but if TSA is producing
-- many records then lua will accumulate a variety of those references.
-- For some sites, the TSA data can be very large.
-- Ordinarily, lua will gc based on its perceived memory usage
-- but the memory consumed by the shaping data is largely
-- invisible to lua because it is an indirect Arc<> to the
-- bulk of the data.
-- So we explicitly collect garbage now to encourage lua
-- to drop the un-referenced shaping data before we go
-- to sleep and keep things better trimmed.
collectgarbage()
kumo.sleep(30)
end
end)