From 63150cae5fb6bd178c0c963730cac29dce582efc Mon Sep 17 00:00:00 2001 From: =?utf8?q?Vladim=C3=ADr=20=C4=8Cun=C3=A1t?= Date: Mon, 27 Feb 2023 13:23:44 +0100 Subject: [PATCH] doc/architecture-gc.rst: describe how GC operates The current code is really simple, so a whole summary fits easily. --- doc/architecture-gc.rst | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/doc/architecture-gc.rst b/doc/architecture-gc.rst index 257a48016..b57c857c3 100644 --- a/doc/architecture-gc.rst +++ b/doc/architecture-gc.rst @@ -1,3 +1,12 @@ ***************** ``kres-cache-gc`` -***************** \ No newline at end of file +***************** + +The garbage collector is a simple component which keeps the shared cache from overfilling. +Every second it estimates cache usage and if over 80%, records get deleted in order to free 10%. (Parameters can be configured.) + +The freeing happens in a few passes. First all items are classified by their estimated usefulness, in a simple way based on remaining TTL, type, etc. +From this histogram it's computed which "level of usefulness" will become the threshold, so that roughly the planned total size gets freed. +Then all items are passed to collect the set of keys to delete, and finally the deletion is performed. +As longer transactions can cause issues in LMDB, all passes are split into short batches. + -- 2.47.3