Ajuste de um servidor Discourse para desempenho

Existem guias (ou tópicos aqui no fórum) que fornecem dicas sobre como otimizar um servidor que hospeda sites Discourse para obter melhor desempenho?

Executei o ./Discourse-set e ele configurou um quarto da RAM (para 4096 MB) e adicionou 8 workers do Unicorn. Mas há algo mais que possamos fazer ou ajustar?

O servidor possui 64 GB de RAM ECC e dois SSDs de 512 GB NVMe (em um array RAID). Ao observar o comando top, apenas cerca de 5 GB de memória estão sendo utilizados, com 57392484 avail Mem. Ele também executa outros sites fora do Docker, mas eles não consomem muitos recursos, e o MySQL já está otimizado para um banco de dados grande de 2 GB. As médias de carga geralmente ficam abaixo de 1,0 (normalmente entre 0,50 e 1,0, ocasionalmente ultrapassando esse valor). Não foram relatados problemas, mas espero aproveitar ao máximo o servidor.

Estou pensando em começar dobrando o db_shared_buffers… e o que dizer sobre #db_work_mem: "40MB", que atualmente está comentado?

Todas as informações e dicas são bem-vindas :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: