Skip to content
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

Open
grahamperrin opened this issue Sep 18, 2022 · 6 comments
Open

Memory footprint reductions #86

grahamperrin opened this issue Sep 18, 2022 · 6 comments
Assignees
Labels
question Further information is requested

Comments

@grahamperrin
Copy link
Contributor

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):

image

  • with this much memory, the preceding run of gitup ports succeeded
  • with an earlier boot with less memory (1,536 MB), gitup ports led to killed.
@johnmehr johnmehr self-assigned this Sep 18, 2022
@johnmehr johnmehr added the question Further information is requested label Sep 18, 2022
@johnmehr
Copy link
Owner

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.

@grahamperrin
Copy link
Contributor Author

Thanks, and no apology necessary …

johnmehr added a commit that referenced this issue Nov 3, 2022
@johnmehr
Copy link
Owner

johnmehr commented Nov 3, 2022

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! :)

@grahamperrin grahamperrin changed the title Killed (insufficient memory, presumably) Memory footprint reductions May 8, 2023
@artkiver
Copy link

artkiver commented Nov 18, 2023

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.

@grahamperrin
Copy link
Contributor Author

8GB

That surprises me. I have used gitup in virtual machines with far less memory.

@johnmehr
Copy link
Owner

I will have a lot more free time next month to finish working on this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants