All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Ruby on low memory systems
Hi all,
I am using Gitlab (http://gitlabhq.com) for a while as my private (free) github clone.
Works great, but it is in Ruby which seems to be kind of a memory hog. It works with nginx server,
so web server weight shouldnt be the problem. I am currently using it on a large box, but thinking about
moving it to a smaller one as I have found need for the larger box and nginx + apache2 on port 80 seems pretty difficult to handle (or it might be with iptables). So I think about splitting those 2 up.
Any advice and minimum memory requirements? It looks like about 256mb ram now for ruby + gitlabhq install,
which is pretty much for a site only used by about 5 users.
Regards and thanks for your time and input,
Comments
@breton: what is that. Apple Juice? I think that's old apple juice he's drinking.
I've tried running gitlab on a openvz vps with 256mb (non-vswap), but got out of memory issues every now and then..
On a vps dedicated to running gitlab I get this (again openvz, but this time with vswap):
Main 'problem' are the 4 ruby processes of gitlab itself.
I have searched, but found nothing to reduce the memory usage of ruby apps.
I recall the authors having a poll asking users if they are running gitlab on systems with less than 512mb ram (that page gives a 404 now), I consider that a hint not to expect gitlab to run in a low memory environment..
p.s. My gitlab installation only contains a handful of php projects
I have no idea about gitlab and it's been a long time since I've bothered with ruby (memory hog…) but there definitely has to be a way of configuring it to use only 1 worker which would be more than enough for a few users. I used to run redmine on nginx/passenger on 128MB without issue (single process).
@FieldMoose That sure helps, down to 184MiB ram usage :-)
Cool; may be worth looking @ nginx/passenger as a combination (I'm assuming you're using unicorn still), you may see a further decrease (I pretty much exited rubyland as unicorn was becoming popular so can't really comment; at the time though I was getting my best performance to weight from passenger).
Gitlab/NGINX/Phusion Passenger Tutorial
I'm running a Rails app on a BuyVM 128 (yes, you read that correctly!) and found that the most memory efficient configuration was running nginx as the front-end webserver and running the app in a single mongrel process. (The app itself is a back-end to a larger system and on a busy day would get less than 300 hits, so a single process is sufficient.)
128mb OVZ? That is impressive
@kiwidave: Cool!
I'm currently trying the nginx/passenger combination, at first glance both ram usage and subjective performance are at about the same level as with nginx/unicorn. Will give it some more time and test nginx/mongrel as well.
I'm currently running nginx/thin, total system memory usage is currently 141MB on an OpenVZ VPS. That's with 2x thin servers, which each use about 70MB. I once ran this same setup on my 128MB P3 using only 1 thin server.
As I said I'm pretty much out of the loop with ruby now; interested in your findings though.
@Kuro You're not speaking of gitlab I assume? With gitlab the resque-worker already uses about 40-60M..
@FieldMoose Did some limited 'synthetic' testing. I've setup a fresh debian 6 32bit system at a 256M ram/ 512M swap xen vps to play with. Idle system used 18M ram.
To have something to work with, I pushed a copy of the Rails github repository to the gitlab test installation, this repository has over 30,000 commits (72M) in it, which should be enough to stress things a little.
Tests were done using nginx in combination with either thin, passenger or unicorn. The memory usage (in MiB, including swap) of the whole vps after a series of 'events' is displayed below in the following format; event: thin | passenger | unicorn. All three servers were configured to use one worker. The system was rebooted between the different servers, the events I came up with are the following:
When using unicorn, gitlab wasn't able to calculate the diff at all; 502 Bad Gateway every time (didn't try to find out why). While thin and passenger both needed the same amount of time (stopwatch) to calculate the diff and render the graph, passenger was noticeably faster (feeling) when browsing commits and files.
The above is probably not very representative of every day use, but I think I'll stick with passenger for now and see what happens.
Correct, I was running redmine. Interesting results, I'll check out passenger next time I do any work on my redmine box