New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
OpenStack is the most complete and the most complex open source cloud operating system.
OpenStack installation and management has a considerable entry barrier. Prepare for some months of documentation and testing.
I recommend OpenStack-Ansible for deployment, not easy to manage, but offers the foundation for features upgrades and re-configurations, as well.
One average 4 core, 16-32GB of RAM dedicated server for the OpenStack controller with all basic services to offer VMs is enough for hundreds of virtual machines.
Interesting, I might give it a try with OpenStack-Ansible. Would it be enough to get it working with Fleio?
We'd only want local storage.
OpenStack-Ansible would be enough for about anything OpenStack, including Fleio.
That, too. Easier/less OpenStack projects to setup then.
Yeah. Glacier would be needed for snapshots I think. Heh. So that would be another one? I checked the Openstack-Ansible. I think I will give it a try tomorrow.
I mean, keep in mind that my Gogs instance (with a ton of repos) uses 60 MB. "2GB or 4GB, depending on your usage level" is an absolute shitton of resources compared to that. I'm fairly sure that GitLab is the most resource-hungry self-hosted option available for repository/project management, other than maybe Atlassian's stuff.
I can't say I share that experience... while UX has improved in a release a year or two ago, it's still a very clunky and chaotic interface. That's a common complaint about it, too.
I mean, it has a massive featureset, I won't deny that. But for basic project hosting? You're really probably better off with Gitea.
I don't try to run it on my watch, so who gives f. about 2GB of RAM?
I'm surprised. I've never had any problem finding stuff instantly in UI ...
For single repo, single user, basic features you're probably right.
I mean, if you're running an entire (software) company on it, sure, 2GB is nothing. But when it runs on a personal server alongside a bunch of other stuff that all also need RAM, then it becomes a bigger issue. Especially when relatively speaking, it isn't doing much for you, and the RAM usage can't really be justified by the functionality it implements.
You may just be used to it
Most UIs can be learned when you work with them (or a lookalike UI) enough, but the problem with Gitlab's UX is that it's not intuitive to somebody who hasn't worked with it before. Again, less of a problem in a company that relies on it and trains for it, but not great for eg. community projects where you want easy onboarding.
Gitea works fine with multiple users and organizations, too.
You need Glance for OS images as well, even if you don't provide snapshots.
This would be the minimum project list for VMs:
https://docs.openstack.org/install-guide/openstack-services.html#minimal-deployment-for-stein
I thought it would be Rocky? Isnt that a different version?
Stein is the latest, Rocky is the previous (order of the alphabet for first letter, e.g. Train is next).
Damn. Got it. Thanks. 😁
Tangentially, I've often found this page useful as a directory of self-hosted goodness:
https://github.com/Kickball/awesome-selfhosted
Anyone tried any of the self-hosted IDEs? Seems kind of cool - do all your dev in the cloud, complete portability no matter where you sit down. Though honestly, I'm still a vim man for lots of things...
Self hosted IDE seems nice... but.... IntelliJ
As I'm a Gitea user myself, I appreciate the small footprint it comes with when hosting personal projects. However OP's project is 10GB big. Whether Gitea can handle that size or not is worth some investigation. Maybe it does need 1 or 2GB memory to handle?
I mean, getting a Gitea server running is fairly easy and cheap. OP can just give it a shot and see how it works.
Hello. The project itself is about 30MB. I have 10GB of assets.
I see. Then Gitea (or gogs) should be more than enough to handle the project.
On the other hand, I checked that GitLab had a limit of 10GB on size of a project but I don't know if assets (LFS) counts. You can do a bit more investigation on that too. GitLab.com has been running very well for some of my other projects.
That is for gitlab. But you can set your own limit on self hosted gitlab.
I tried gitea and it was amazing. I might will give onedev.io a try.
Used eclipse che before. Setting up https is a nightmare with docker
coder (vscode on web) was pretty good, although seemed less secure (only a password protecting the web ui).
I don't really see why that would need more memory. Your projects are stored on disk, not in memory; and ultimately an application like Gitea or Gitlab doesn't do much more than shoveling data in and out of the DB, and invoking external processes. Memory usage is more likely to correspond to requests/second than anything else.
I now have a bare bones gitea running on a NanoKVM 512MB. It is using 104MB rss, 670MB virtual. That is much bigger than the 40MB I remember from old gogs, but it's tiny compared with gitlab. Still, Fossil is a heck of a lot smaller. I think the day will come when Fossil has to migrate to the Git protocol.
I use gogs. Its ok
It looks like my gitea instance allocated 128MB (some just virtual) but is actually using around 50MB. Just something about how the Golang memory system works. Anyway it was easy to install from binary (from source was harder last time I did it), seems to run ok on small vps, and has stuff that Gogs was missing some time back (don't know about now). It still seems bloaty but given today's machines it's not a problem.
That's pretty much what (almost) any software does.
And it doesn't mean it won't require RAM for those processes, MySQL cache, file system cache, search servers, redis/memcached, code with internal data structures etc.
But some git operation can use much more RAM than that right?
But there just isn't much data going on here. There is a table of user accounts, repos per user account, things like that. Generously that's maybe a kilobyte per user and another KB per repo, plus some stuff for issues etc. Then there are a bunch of static git repos on disk. File system cache is a kernel thing and doesn't count as ram used by the user process.
My (very low traffic) instance is set up with sqlite3 instead of mysql so that should also decrease footprint a bit. Again it's using 20x more ram than Fossil while having comparable features, so something is odd.
Does it happen to run in an OpenVZ container?
I have it on nanokvm right now, but no reason it couldn't run in openvz. It's just a web server.
Gitlab now idles at 2.35GB usage after 6weeks uptime(checked before I upgraded the docker image) .
I think I could shave another 350M by reducing the unicorn worker count by 1,but hey RAM is plenty on my 22eur dedi (especially with KMS enabled) .
Giving the VM 8GB makes fetches from page cache near instantaneous for hot repos.
Gitlab does a shit-ton features . I haven't even begun to scratch the surface.
Truthfully I've always felt ok with plain command line git, except being able to let people browse code over the web is nice.
Probably trying to reduce memory fragmentation.> @intovps said:
Well, yes and no. Your typical boring business/management software, yes, that's generally just a frontend for a database. But there are definitely categories of software (games, batch data processing, ...) that don't have those characteristics. Those can take gigs of memory without me batting an eyelid, but when boring line-of-business-y software with no persistent in-memory state does, it becomes questionable.
Some degree of cacheing, sure. But for example "code with internal data structures" is not a justification here, given that the workload that a project management tool handles is almost exclusively request/response (and therefore any in-memory state can be thrown away after handling a request, and it doesn't explain persistent memory usage).
Same story for search servers and databases; unless you have a particularly high-performance setup, you're probably not storing your entire dataset in memory, but only the things that you've recently used, or maybe some first-level indexes. That doesn't meaningfully grow with the amount or size of projects, users, and so on.
As far as I can tell, there is no legitimate reason for Gitlab to persistently need this much memory for what it does.