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 curtidas

Eu também tenho pesquisado nos fóruns sobre isso.

Existem (ou existiam) alguns tópicos sobre ajuste. A maioria dos bem-sucedidos, eu acho (exceto este), fornece detalhes precisos sobre recursos disponíveis, db_shared_buffers e outras configurações, e quais são os problemas, talvez com a saída do htop ou outras ferramentas. Qual o tamanho do seu banco de dados? Que problema você está tendo? (Você pode querer iniciar um novo tópico)

1 curtida

Obrigado! Nenhum problema, ainda. Apenas notei alto uso de memória, mas não é um fórum sobrecarregado. Estou apenas acostumado a pensar proativamente e verificar quais recursos estavam mais em uso. Isso é apenas em um VPS de 3 GB com 6 núcleos @ 3,5 GHz. Não é lento, muito rápido, apenas posso ver o uso de memória se tornando um problema futuro e estou curioso sobre o que posso ajustar.

Farei mais leituras sobre aplicativos Ruby on Rails em geral e otimização. Obrigado novamente.

1 curtida

Dependendo de qual medida de “uso” você quer dizer, isso pode ser normal. Mas com 3GB, provavelmente não há muito o que ajustar, pois se você executou ./discourse-setup, as suposições dele provavelmente são Boas o Suficiente.

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

Disponível é ~ 900M. Ainda não é um problema. Mas um problema não me trouxe aqui. Gostaria de saber o que fazer se/quando a memória disponível se tornar um problema no futuro. Além de adicionar mais memória, é claro.

Neste nível, a única coisa real a fazer será adicionar mais RAM. Se você tiver 8 ou 16 GB, há algumas coisas a fazer. Se for o caso, você pode querer adicionar mais 1 GB de swap, mas provavelmente ficará bem.

Se você executasse ./discourse-setup, ele teria criado um arquivo de swap de 2 GB. Você pode ter problemas ao fazer uma reconstrução.

Ok, então consegui quase dobrar o uso de memória disponível alterando o padrão de instalação de:
UNICORN_WORKERS: 8
para
UNICORN_WORKERS: 4

Em seguida: sudo ./launcher rebuild app

Agora estou configurando o monitoramento do PostgreSQL e verei o que está acontecendo lá.

Sempre há um ponto em que algum recurso se torna um gargalo. Mas seu servidor atualmente parece excessivamente superdimensionado para mim.

Você usará mais memória quando tiver mais processos Unicorn.
Você precisará de mais processos Unicorn quando tiver mais tráfego em seu site.

Vejo todos os processos Unicorn usando 0,0% de CPU e apenas worker[0] parece estar realmente fazendo algo.

Você reduziu a memória executando menos Unicorns. Isso é bom, porque você não parecia usá-los de qualquer maneira. Mas a memória disponível é, na verdade, uma coisa ruim. Você está otimizando para a variável errada.

Memória não utilizada não lhe traz nada. Significa que você está pagando por algo que não está usando de qualquer maneira. Se você tem 2 GB disponíveis o tempo todo*, você poderia reduzir o tamanho do seu servidor e economizar algum dinheiro.

*) Reconstruir o Discourse consumirá mais memória, então você precisa verificar quanta memória está disponível durante a reconstrução. Na prática, não vá abaixo dos 2 GB totais e/ou certifique-se de ter swap suficiente, como Pfaffman já disse.

1 curtida

Não está correto. Memória “livre” sem fazer nada é ruim. Mas memória “disponível” é memória sendo usada pelo sistema que pode ser facilmente liberada, o que é uma coisa boa. :slight_smile:

Ou oficialmente:

Memória disponível: Estimativa de quanta memória está disponível para iniciar novos aplicativos, sem troca.

Fonte: man free

Conforme a captura de tela abaixo, a memória livre está praticamente inalterada. Portanto, quase toda a memória do sistema está sendo usada. No entanto, o sistema fará menos trocas agora porque há mais memória disponível que pode ser liberada quando necessário.

…sim, prefiro liberar memória se não estiver sendo usada até que o tráfego exija quaisquer alterações.

Obrigado novamente.

Eu acho que ruim aqui significa que custa, mas não dá nada. Essa é uma forma bastante comum de pensar, porque quando se precisa de mais recursos, também fica mais caro — e a RAM é uma parte custosa nessa equação.

E se você não tem muito dinheiro para desperdiçar, é meio estúpido pagar demais (expressão publicitária finlandesa, sem ofensa :rofl: )

1 curtida

Sim, exatamente, com relação à memória livre. No entanto, “memória disponível é na verdade uma coisa ruim” …é realmente o que eu estava abordando. :slight_smile: