My local `lmdb store` directory is currently at 46GiB which

Question

My local `lmdb store` directory is currently at 46GiB which is a fairly hefty proportion of my full disk AIUI pantsd is meant to be doing some GC on it but if so there s a lot of non garbage Can I introspect the GC process Is there a way to force a harder GC

curved-television-6568 · Answer

`rm rf ~ cache pants`

witty-crayon-22786 · Answer

` pants d pants log` should record a GC every 4 hours iirc

broad-processor-92400 · Answer

Haha maybe slightly less forciful GC than `rm` sweat smile I ll have a look at the log thanks

witty-crayon-22786 · Answer

witty-crayon-22786 · Answer

could should be a `tokio` task at this point

broad-processor-92400 · Answer

I see various lines like ```08 22 09 39 INFO Garbage collecting store target size=28 800 000 000 08 22 11 56 INFO Done garbage collecting store``` I ll increase the log level and see what else comes out of it

witty-crayon-22786 · Answer

that s the relevant one

broad-processor-92400 · Answer

Ooh looks like I could potentially also use the separate fs util tool to force one and with `ShrinkBehavior Compact` which sounds more aggressive than `ShrinkBehavior Fast` thinking face

witty-crayon-22786 · Answer

yeeep

witty-crayon-22786 · Answer

Compact is not natively supported though it requires closing recreating the database

witty-crayon-22786 · Answer

would definitely welcome a patch that figured out how where to do that safely

broad-processor-92400 · Answer

ah yeah I see it copying to separate files

broad-processor-92400 · Answer

anyways thanks for the tips should be enough for me to work out if our repo is just that huge or if there s something else going

witty-crayon-22786 · Answer

LMDB has served its purpose fairly well but it s not my favorite not being async compatible not having a compacting GC occasional corruption needing to shard etc

bitter-ability-32190 · Answer

Don t worry < broad processor 92400> soon your large files will just exist on disk triumph

witty-crayon-22786 · Answer

true that will extend the lifetime of LMDB a bit =

witty-crayon-22786 · Answer

yea assuming that the reason you haven t seen things GC d is in fact the Compact vs Fast distinction

bitter-ability-32190 · Answer

Although the large files won t be GC d I think So maybe worse for you sweat smile

witty-crayon-22786 · Answer

they ll need to be haven t added that feedback to the PR yet =x

bitter-ability-32190 · Answer

Ruh roh

fast-nail-55400 · Answer

just run `tmpwatch` on the large file directory assuming atime is updated

witty-crayon-22786 · Answer

yea should be possible to do it in the exact same loop as the LMDB store just create timestamps from atimes

bitter-ability-32190 · Answer

I m more worried about collecting while the file is still symlinked flushed

witty-crayon-22786 · Answer

GC handles that

witty-crayon-22786 · Answer

by not collecting things that are reachable from memory

bitter-ability-32190 · Answer

Yaaaay I think

broad-processor-92400 · Answer

Getting very distant from my original question but Are atimes reliable enough for this purpose I was under the impression some file systems either don t support them and or can be configured to be pretty relaxed about updating them

witty-crayon-22786 · Answer

if not can touch to bump the mtime instead

broad-processor-92400 · Answer

Even with ` ltrace` it seems there s no additional logging beyond the `INFO` above ah well The fact that <https github com pantsbuild pants blob 3304f13aecd534f5581b35104ad77bea41809b5d src rust engine fs store src lib rs L1099 L1106> didn t trigger i e the GC successfully reduced the reported size below 28 8GB would suggest that indeed this might be a fragmentation issue since 46GB is a little larger than 28 8GB I ll try a `ShrinkBehavior Compact` GC to confirm

broad-processor-92400 · Answer

yeah the same GC via `fs util gc target size bytes 28800000000` resulted in it the directory being the expected size