Tuning a Discourse server for performance

Are there any guides (or Topics here on the forum) that provide tips on tuning a server that hosts Discourse sites for performance?

I ran the ./Discourse-set and it set a quarter of the ram (to 4096mb) and added 8 unicorns workers - but is there anything else we can do, or tweak these?

The server has 64GB ECC Ram and two 512GB NVMe SSDs (in a raid array). Looking at top, only around 5GB of memory us being used, with 57392484 avail Mem. It does run other non-Docker sites, but they don’t use up much of the resources and MySQL is already tuned for a large 2GB db. Load averages are generally below 1.0 (usually around 0.50 up to 1.0 with occasionally going over). No problems have been reported, but I am hoping to utilise as much of the server as possible.

I’m wondering whether to start by doubling db_shared_buffers… and what about #db_work_mem: "40MB" which is currently commented out.

All info/tips appreciated :smiley:

3 Likes

I’ve also been searching the forums for this.

There are (or were) a few topics about tuning. Most of the successful ones, I think (excepting this one), provide some precise details about available resources, db_shared_buffers and other settings, and what the issues are, perhaps with output from htop or other tools. How big is your database? What problem are you having? (You might want to start a new topic)

1 Like

Thanks! No problems, yet. Just notice high memory usage but not a busty forum. I’m just rather used to thinking proactively and checking what resources were in use most. This is just on a 3GB VPS with 6 cores @ 3.5 GHz. Not slow, really fast, just can see memory usage becoming a future problem and curious about what I can tweak.

Will do some more reading up on general ruby rails app and optimization. thanks again.

1 Like

Depending on what measure of “usage” you mean, that could be normal. But with 3GB, there probably isn’t much tuning to do, as if you ran ./discourse-setup it’s guesses are probably Good Enough.

1 Like
free -h
              total        used        free      shared  buff/cache   available
Mem:          2.9Gi       1.8Gi       167Mi       100Mi       1.0Gi       895Mi
Swap:         1.0Gi       587Mi       436Mi

Avaiable is ~ 900M. Not a problem yet. But a problem didn’t lead me here. Would like to know what to do if/when available memory becomes an issue in the future. Besides throwing in more memory of course.

At this level, the only real thing to do will be to throw more RAM at it. If you have 8 or 16GB, then there are some things to do. If anything, you might want to add another GB of swap, but you’ll probably be OK.

If you’d run ./discourse-setup, it would have created a 2GB swapfile. You could run into issues when you do an rebuild.

ok, so I was able to just about double available memory usage by changing the installation default from:
UNICORN_WORKERS: 8
to
UNICORN_WORKERS: 4

Then: sudo ./launcher rebuild app

I’m now setting up monitoring of PostgreSQL and will see what’s going on there.

There is always a point in time where some resource becomes a bottleneck. But your server currently looks heavily overdimensioned to me.

You will be using more memory when you have more Unicorn processes.
You will need more Unicorn processes when you have more traffic on your site.

I see all Unicorn processes using 0.0% CPU and only worker[0] seems to be actually doing something.

You reduced memory by running less Unicorns. That’s good, because you didn’t seem to use them anyway. But available memory is actually a bad thing. You’re optimizing for the wrong variable.

Unused memory buys you nothing. It means you’re paying for something you’re not using anyway. If you have 2 GB available all the time*, you could downsize your server and save some money.

*) Rebuilding Discourse will consume more memory so you need to check how much memory is available during rebuilding. In practice, don’t go under the 2 GB total and/or make sure you have enough swap as Pfaffman said already.

1 Like

Not correct. “Free” memory doing nothing is bad. But “available” memory is memory being used by the system that can be easily freed is a good thing. :slight_smile:

Or officially:

Available memory: Estimation of how much memory is available for starting new applications, without swapping.

Source: man free

As per the screenshot below, free memory is just about unchanged. So nearly all of the system’s memory is being used. However, the system will swap less now because there’s more available memory that can be freed when needed.

…yes, I prefer to free up memory if not being used until such time traffic requires any changes.

thanks again.

I reckon bad means here it costs, but gives nothing. That is quite common way to think, because when one needs more resources it will be more expensive too — and RAM is a costly part in that equasion.

And if you don’t have too much money to waste it is just kind of stupid pay too much (finnish ad-expression, no offence :rofl: )

1 Like

Yes exactly, with regards to free memory. However, “available memory is actually a bad thing” …is really what I was addressing. :slight_smile: