Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Ruby on low memory systems
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.

Ruby on low memory systems

djvdorpdjvdorp Member
edited July 2012 in General

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

  • bretonbreton Member

    Ruby
    low memory

    image

  • @breton: what is that. Apple Juice? I think that's old apple juice he's drinking.

  • happelhappel Member
    edited July 2012

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

    free -m
                 total       used       free     shared    buffers     cached
    Mem:           512        339        172          0          0         34
    -/+ buffers/cache:        304        207
    Swap:          512          3        508
    

    Main 'problem' are the 4 ruby processes of gitlab itself.

    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
    gitlab    9850  0.0 10.6 130872 55840 ?        Sl   Jul22   0:15 unicorn_rails master -c /home/gitlab/gitlab/config/unicorn.rb -E production -D                                               
    gitlab    9869  0.0 16.4 161492 86016 ?        Sl   Jul22   1:46 unicorn_rails worker[0] -c /home/gitlab/gitlab/config/unicorn.rb -E production -D                                            
    gitlab    9872  0.0 23.8 182908 125140 ?       Sl   Jul22   2:05 unicorn_rails worker[1] -c /home/gitlab/gitlab/config/unicorn.rb -E production -D                                            
    gitlab    9919  0.0 11.8 135928 62328 ?        Sl   Jul22   0:38 resque-1.20.0: Waiting for post_receive,mailer,system_hook  
    

    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

    Thanked by 1djvdorp
  • 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).

    Thanked by 1djvdorp
  • happelhappel Member

    @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

    Thanked by 1djvdorp
  • 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.)

    Thanked by 1djvdorp
  • @kiwidave said: BuyVM 128

    128mb OVZ? That is impressive

  • happelhappel Member

    @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.

  • KuroKuro Member

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

  • FieldMooseFieldMoose Member
    edited July 2012

    As I said I'm pretty much out of the loop with ruby now; interested in your findings though.

    @happel said: 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.

  • happelhappel Member
    edited July 2012

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

    • after first pageview: login to gitlab dashboard
    • after browing: have gitlab load the last 1000 commits in a list, render the commit history in a graph, browse through the source, show the wiki etc.
    • diff: have gitlab calculate the diff between HEAD and a certain commit. Which happens to be 795 commits in the past. (results in a ridiculously large diff of 662 pages)
    • 5min idle: browse away from diff and give the server some time to unwind.
    after first pageview:   140  |  170  |  165
    after browsing:         160  |  175  |  185
    after diff:             195  |  195  |  DNF
    after 5min idle:        165  |  155  |  180
    

    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.

  • KuroKuro Member

    @happel said: @Kuro You're not speaking of gitlab I assume?

    Correct, I was running redmine. Interesting results, I'll check out passenger next time I do any work on my redmine box :)

Sign In or Register to comment.