Rescaling the server, which configs need to be changed? - unicorn workers, memory, etc

Product Support Self-hosting

AI-generated summary

In a discussion titled “Rescaling the server, which configs need to be changed? - unicorn workers, memory, etc.”, users explore how to adjust Discourse configurations after changing server hardware. Alon1 asks if there’s a guide for tuning settings like UNICORN_WORKERS and db_shared_buffers, noting that auto-configured values don’t adjust automatically after rescaling and suggesting a dashboard alert for mismatched hardware. Stephen cautions that such alerts assume Discourse runs alone on the server, and recommends 2 unicorn workers per CPU core and 25% of system memory for db_shared_buffers. pfaffman clarifies that running discourse-setup will reconfigure values based on new hardware, or users can manually adjust them. Muhammed_EKİCİ asks for pre-resize precautions, to which Falco advises backing up both a full site backup and the app.yml file. Overgrow asks if db_shared_buffers can be changed without rebuilding, and the answer implies it requires a rebuild via ./launcher destroy app and ./launcher start app. The thread centers on safe, manual tuning of server resources for Discourse after hardware changes, with emphasis on backups and understanding default auto-configuration limits.

1

TLDR: Is there a guide or a list of recommended configurations to consider when rescaling a server?

When installing Discourse for the first time on a server, there are some settings that are auto-set.
One convenience that the cloud offers is to simply change the instance type to a different one with more/less cpus and memory.
As far as I understand, the automatic configurations don’t auto-adjust to the new server (it could be nice to have an alert on the Admin Dashboard that your Discourse configuration don’t seem to match the hardware it is running on).

For example, I considered these settings from the app.yml file:

## Set db_shared_buffers to a max of 25% of the total memory.
## will be set automatically by bootstrap based on detected RAM, or you can override
db_shared_buffers: "4096MB"

## can improve sorting performance, but adds memory usage per-connection
#db_work_mem: "40MB"

## How many concurrent web requests are supported? Depends on memory and CPU cores.
## will be set automatically by bootstrap based on detected CPUs, or you can override
UNICORN_WORKERS: 4
2

That would assume that Discourse is the only thing running on the server, which isn’t always the case.

I usually specify two unicorn_workers per core, and 25% of the system memory as db_shared_buffers

3

If you run discourse-setup it will change to the suggested sizes. But you’re looking at the suggestions, so you can just do it yourself.

4

Hello. It’s time to increase server features. In order to change the processor and ram properties of the server, I need to turn it off. Is there anything important I should do before resizing the server? I want everything to be in place and working when I come back.

5

I’d download a full backup and a copy of the app.yml file in case it doesn’t come back.

6

Is it possible to change db_share_buffers without rebuild?

cd /var/discourse
./launcher destroy app
./launcher start app