Home / server / Questions / 80047
Accepted
Jakub Arnold
Asked: 2009-10-31 14:50:35 +0800 CST

How to scale down for low memory server?

  • 772

I'm having problem with one of my Rails applications, that runs on 365MB VPS, which seems to be not very much. When there are more than 3-5 users at the same time it runs out of memory and starts to use swap, which is f****** slow.

As I look into top, I can see that there are many spawned instances of mysql (much more than Rails processes). Is this normal?

How do you recommend to scale down application for low memory enviromnent?

I'm using Ubuntu 9.04, Apache2.2 with mod passenger, MySQL 5.075 and Ruby 1.8.7

edit: After your suggestions, I upgraded VPS to 540MB, which for now seems to suffice. However, I'm just a poor student, so I can't pump too much money in some project I'm doing mostly for myself, untill it starts to pay back at least something.

mysql

4 Answers

  1. You will spend a lot of time (and hence money) fiddling with tuning parameters to possibly produce a small memory saving. You'll get a lot more bang for your buck by just upgrading the RAM on your VPS.

    • 4
  2. Best Answer

    There will be several mysql threads, not processes. Some version of "Top" and "ps" show threads as if they were separate processes.

    MySQL can be tuned as much as you like. The best way to tune it is to use just a single engine for all your tables - if you're using InnoDB, use ONLY InnoDB.

    Then tune the buffers as you see fit - the main ones are the MyISAM key cache and innodb buffer pool. If you're using only MyISAM, disable in the innodb engine entirely with skip-innodb in the my.cnf.

    As far as Apache is concerned, run the least number of MaxClients you can; either disable keepalive or set the timeout very low - keepalive connections will still tie up a (hefty) Apache process.

    Of course doing any of these things may be detrimental for performance, so test it on a non-production system if you care about performance regressions.

    It may be more cost effective just to buy more ram than spend your time tuning for such a tiny box. At our work each developer has a blade with 16G of ram just for test purposes. This is considered reasonable and not very expensive.

    • 2

  3. You're going to need to dig in more and find out exactly what's using your memory, how much each process takes, look for potential leaks and so on. But my advice is going to echo the others: get more RAM instead. 365MB is peanuts, and won't scale at all. The problem is compounded by your choice of framework - have a read of the Twitter experience here.

    Selected outtake:

    All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.It’s also worth mentioning that there shouldn’t be doubt in anybody’s mind at this point that Ruby itself is slow.

    • 1

  4. lowendbox.com is a nice bookmark worthy site related to this issue (optimizing low memory servers)

    The following doesn't of course match your existing setup, but consider switching to a lighter httpd like nginx och lighttpd. Either of these two should save you a lot of ram, at least per static http connection. Passenger is available for nginx.

    • 1