New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory footprint reductions #86
Comments
I'm very sorry for the delay in responding to this (I found an issue during testing that got in the way which I'm about ready to commit). For cloning current, it looks like a minimum of 2GB of memory is required if the "low memory" option is turned off but this drops to 450MB if it is enabled. For a large pull, this drops to 1.2GB/1GB if "low memory" is disabled/enabled. A small pull only required 256MB. |
Thanks, and no apology necessary … |
I just committed an update that reduces the large pull footprint for current to 215MB when the low memory option is set and I believe I should be able to get the clone footprint to match. More savings to come! :) |
I'm curious if there is any progress on this? Not too long ago I was running into issues even on a VM with swap until I bumped the RAM allotment to 8GB, for rigamarole syncing of /usr/src and /usr/ports. Previously, FreeBSD handled syncing /usr/src and /usr/ports like a champ with systems with 256MB of RAM using csup and svnlite, but I clearly lost the battle against git despite trying to temper zb/angryskul/Alfred Perlstein's enthusiasm for such things when we were both working at iXSystems many years ago with jkh (this was before FreeBSD switched to git and I was still happily using snvlite from base). At the time, fossil-scm was also a total non-starter for FreeBSD given its git compatibility would barf when trying to contend with (at the time, merely git mirrors) of FreeBSD's /usr/src. I wonder if Got (https://www.gameoftrees.org) might be less precarious for a sensibly licensed git compatible alternative these days? I haven't tested its memory requirements nor syncing /usr/src nor /usr/ports using Got at the moment, but I saw this issue still open after recently reflecting on some experiences with gitup. |
That surprises me. I have used gitup in virtual machines with far less memory. |
I will have a lot more free time next month to finish working on this issue. |
For systems where swap is not enabled, what (if anything) might you consider a minimum system memory requirement for gitup to clone e.g. current?
TIA
Related:
Context
I assume that the
gitup current
death pictured below was the result of insufficient memory (2,048 MB given to the VirtualBox guest):gitup ports
succeededgitup ports
led to killed.The text was updated successfully, but these errors were encountered: