Help reducing memory

Tutor
1

First, I was really thrilled to be able to get open edX running thanks to Tutor. It’s amazing how tutor has made this possible for me and my small startup company, given how little I know about server admin. It’s now running on a 4GB RAM, 2 CPU DigitalOcean droplet.

However, when I actually started building courses, I quickly found out that it was on the verge of being unusable. Regularly getting 504 timeouts, and just really slow load times loading a page in studio.

I checked out docker stats and saw that tutor_local_elasticsearch_1 is using 1.22 GB memory, which is over 30% of the total memory available. Is this expected? No-one is searching for anything as I’m the only one using the site.

I expect that paying double and getting a 8GB / 4 CPU droplet would solve this, but we can’t afford that at the moment. This is going to be a closed course with under 10 simultaneous users at any time. According to what I read here, it may be possible to reduce memory requirements. That page is on the very edge of my ability to comprehend, but it seems like reducing the number of workers for the LMS, CMS, and xqueue might be able to help.

Here is what I have tried so far, in ~/.local/share/tutor/config.yml:

RUN_FORUM: false
OPENEDX_CMS_UWSGI_WORKERS: 1
OPENEDX_LMS_UWSGI_WORKERS: 1
ELASTICSEARCH_HEAP_SIZE: "0.5g"

I then did a reboot using tutor local reboot. It does seem snappier now, which is great. However, when I run docker stats, I still see elasticsearch is using 1.2GB. While search is an important feature, I would turn it off if this was massively slowly down the system. So I’ve got a few questions:

  1. Is trying to reduce memory available to elasticsearch a good idea?
  2. Why didn’t ELASTICSEARCH_HEAP_SIZE: "0.5g" in my config seem to do anything? I also tried "500mb", then tutor local restart elasticsearch, but to no avail.
  3. Is it a mistake to set the UWSGI workers to 1?
  4. Does anyone have any other suggestions to get the platform running smoothly on this ‘minimum spec’ hardware, considering there will be very few concurrent users?
1 Like
2

I can now answer questions 2 and 3.

2: The reason the config had no effect is that you have to run tutor config save after editing config.yml.
3: It’s fine. The docs suggest setting these to 1 if you’re on a server with low memory.

As for number 4, one thing that might help is by utilising swap. DigitalOcean droplets by default have swap switched off, and they recommend keeping it that way to avoid damage to their SSDs. Fair enough, but if it’s only occassional use of swap that would be fine. I don’t know how to tell if open edX will thrash it or not. I guess I will try it and see.

3

After spending a week of trial and error, I’ve found I have a highly responsive platform (albeit with only a handful of concurrent users). Here are my conclusions:

Is trying to reduce memory available to elasticsearch a good idea?

Yes. Currently I’m using ELASTICSEARCH_HEAP_SIZE: 300m and it seems to work fine.

Why didn’t ELASTICSEARCH_HEAP_SIZE: "0.5g" in my config seem to do anything?

Run tutor config save after making config changes.

Is it a mistake to set the UWSGI workers to 1?

It’s fine. The docs suggest setting these to 1 if you’re on a server with low memory.

Does anyone have any other suggestions to get the platform running smoothly on this ‘minimum spec’ hardware, considering there will be very few concurrent users?

I set the (Ubuntu) server swapiness to 10. Previously it was on 50, and kept trying to swap, and this was maxing out the CPU.

The good news is that it seems to be running really smoothly now even on the minimum spec hardware.

1 Like