Open edX: Reducing Memory Consumption

This page is extremely rough. It’s just my rough notes with very little editing or checking. Be warned!

If you’re just developing on your laptop/desktop, run Devstack. it is a lot easier to develop on than the full production server and “only” uses 2GB of RAM.

The stock edX Ubuntu deployment is set up to give you good performance, but it assumes that you have a lot of hardware available.

The recommended config for the edX Ubuntu deployment recommends an Amazon instance with 4GB of RAM. There are two problems with this:

4GB of RAM is a lot to allocate to a VM in development. If you want to demo or develop on your laptop… not a lot of laptops have 16GB of RAM yet, and spending half of your RAM on a VM is annoying.
- For development, 2GB is sufficient, but it’s still chugworthy
4GB Amazon instances are expensive. As of August 2014, they’re about $100/month, so $1200/year just in hosting.
- To put that in perspective, you could buy a really nice desktop computer or server, put it under your desk and use your university’s Internet connection. And have no ongoing costs.
- If you’re in the sort of institution whose IT department charges $15k/year for a server or even $100k (hello, Australian banking sector), then… sucks to be you. I guess Amazon works out cheaper, then.

If you’re running a big edX instance (tens of thousands of students), then yeah, you probably need some bigger hardware and a lot of RAM. If you’re just doing a closed course, 4GB instances are vast overkill.

You can reduce the memory usage to something sane by:

Reduce the number of workers for a bunch of services (lms, cms, xqueue). By default, lms uses 8, and each uses ~80MB of RAM (so 640MB just for the LMS). I use 3 both in dev and production.
- The optimal number here is highly debated. If you’re CPU-bound thenis good, but unless you’re using SSDs, you’re probably not CPU bound. Best to test it and adjust accordingly. Keep in mind that if you’re using regular spinning disks, you’ll probably never peg the CPUs even with many workers; adding workers will just make the disks thrash more. I/O is pretty much always the bottleneck.
- Also, timeout=300? That seems crazy. Who has a 5 minute request? Better to kill it early rather than block all the new requests coming in. Make it 30 seconds, tops (and even then, you’re still boned).
Restart the LMS with /edx/bin/supervisorctl restart edxapp:lms
Restart the CMS with /edx/bin/supervisorctl restart edxapp:cms
Restart xqueue with /edx/bin/supervisorctl restart xqueue
Restart ora with /edx/bin/supervisorctl restart ora
Restart ora_celery with /edx/bin/supervisorctl restart ora_celery
- You might not use it at all, so you could just turn it off
Restarting through supervisor doesn’t seem to change the number of workers; as a stop-gap solution, just reboot the machine (yuck!)
You could also turn off some services, like the grader, forums or java
You could also use zram
Try KSM. Only for KVM VMs right now, but there are some attempts to make it work for all processes, which would be excellent with LXC: https://plus.google.com/+MaksimMelnikau/posts/QfhAchyzYva http://vleu.net/ksm_preload/ http://kerneldedup.org/en http://kerneldedup.org/en/projects/uksm/introduction/ https://github.com/prashmohan/lxc-fork/blob/master/Documentation/vm/ksm.txt

Ian Howson