I’ve got a 2-container install on a DO 8GB droplet that is behaving very strangely.
There is a postmaster (EDIT: now there are two of them) processing eating 100% CPU.
Sidekiq is running, but the Dashboard complains that it’s not checking for updates.
There are some logs like
PG::ConnectionBad (FATAL: remaining connection slots are reserved for non-replication superuser connections ) /var/www/discourse/vendor/bundle/ruby/2.4.0/gems/pg-0.21.0/lib/pg.rb:56:in `initialize'
and
Job exception: FATAL: remaining connection slots are reserved for non-replication superuser connections
The data container has:
db_shared_buffers: "2GB"
db_work_mem: "40MB"
There are 4 unicorn workers in the web container (same as # processors).
The postgresql connection limit needs to be increased. That will cause the database as a whole to use more memory, but based on the free output you’ve got plenty that could be used if required. I’d double the current value, and review errors and resource consumption.
I did that, but I’m still getting a 502 error on the admin dashboard.
The other issue is that this site is using cloudflare with no caching (I’m told). I have included the cloudflare template, but I still suspect something is wrong with cloudflare.
It’s the max_connections parameter in postgresql.conf. I don’t see a tunable for that in discourse_docker, so I suspect you’ll need to play games with a pups exec stanza to make the edit.
As for Cloudflare, all the cloudflare template does it make it so that IP addresses get fixed after going through Cloudflare proxying. It doesn’t do anything to make Cloudflare cache. You might want to keep that in a separate topic, rather than mix them together in here.
Not one for playing games when they’re not necessary, I went into the data container, edited postgresql.conf by hand, doubled max_connections (from 100 to 200) and, LO! it seems that all is well.
I don’t understand just why I’ve not encountered this before or why this is the solution here. The database doesn’t seem that big and the traffic doesn’t seem that high.
Edit: I have played the games and won!
If anyone else cares. . . stick this in data.yml in hooks in the after_postgres section. I put it after the -exec section.
# double max_connections to 200
- replace:
filename: "/etc/postgresql/9.5/main/postgresql.conf"
from: /#?max_connections *=.*/
to: "max_connections = 200"
@pfaffman, isso resolveu para você o problema de alto uso de CPU do “postmasters gone wild”?
Eu modifiquei diretamente o número máximo de conexões no arquivo postgresql.conf (/var/discourse/shared/standalone/postgres_data/postgresql.conf) e executei ./launcher rebuild app. No entanto, não notei nenhuma diferença.
Tentei dar mais e menos memória ao PostgreSQL. Adicionar swap parece ter ajudado (daí a tentativa de dar menos memória ao pg). Uma coisa que fiz e que pode ter ajudado foi fazer backup e restaurar o banco de dados. Ou talvez não tenha feito nada.
Não tenho uma solução mágica, mas essas são as coisas que fiz.
Isso também começou a acontecer comigo, após instalar a atualização para a versão 2.5.0.beta5. Um de cada vez, vejo mais processos postmaster consumindo o máximo de CPU possível, e às vezes eles levam alguns minutos para concluir. Aos poucos, isso consome todos os créditos da AWS do servidor e deixa o fórum todo lento ou até inutilizável.
Aumentar max_connections não teve nenhum efeito, e o mesmo valeu para reconstruir o aplicativo.
Antes de atualizar para a versão 2.5.0.beta5, nunca havia visto isso. Alguma dica de onde eu deveria procurar?
Atualizamos nosso fórum para a versão 2.5.0.beta5 ontem e, desde então, ele está lento e sem resposta. Há algumas tarefas do postmaster no topo que consomem 90-100% da CPU. Isso está fazendo com que várias partes do fórum tenham tempo limite e retornem um erro 502 para os usuários.
As tarefas aparecem e desaparecem, mas enquanto estão ativas, o fórum não é muito utilizável.
Esses não seriam os passos de finalização da atualização do Postgres 12? Acredito que haja alguma limpeza interna necessária após a migração do PG10 para o PG12. A situação persiste por um dia ou mais?
Além disso, para confirmar: eu migrei da PG 10 para a 12 (sei que é possível permanecer opcionalmente na 10, então só quero esclarecer).
Não tenho certeza se isso é relevante, mas ao acessar o resumo de um usuário, o uso da CPU consistentemente dispara para mais de 90% e sempre resulta em um erro 502. As outras seções do perfil parecem funcionar, embora lentamente.
Vou ficar de olho nas coisas ao longo do dia para ver se elas se corrigem sozinhas e atualizarei aqui.
Pode ser que seja necessária alguma limpeza após a migração. Se você verificar o tópico oficial de atualização aqui e ler atentamente a primeira postagem, encontrará detalhes e etapas recomendadas – PostgreSQL 12 update
