Is there any way to stop LFS from causing huge RAM spikes? I’ve had a gitea server for my dev for the last couple years with no issues at 768MB of RAM (in k8s). I’m now starting another project that’ll need LFS and, even when it’s allocated 2GB or 3GB, when some large files are posted it’ll be OOMKilled. This then starts an infinite feedback loop and it won’t start again until I increase its RAM limit.
My guess is that whatever it’s doing to hash the files isn’t written in a way to minimize RAM usage, but instead reads a whole bunch of a file at a time. Is there any way to change the chunk size it uses to read, effectively to set an upper cap on RAM usage used by LFS’s hash calculation?
Or is there another known issue that I’m misattributing to hash calculation?
I’m using this version: docker.gitea.com/gitea:1.24.6-rootless (and yes I know that’s old but … well there is no but there; I should update it, but that doesn’t really change the need to diagnose this issue).
I’m using it as a backup server, so the repo I push is a tree and lfs-pointers only. My code pushes the whole repo pack (trees, lfs-pointer blobs, and a commit), then starts pushing all the LFS files via the HTTPS LFS API. During this process, if a large file is sent, the server is killed and then won’t start successfully without being OOMKilled until I increase the RAM. This tells me it’s not a gradual memory leak and it is pretty specific to LFS object writing.