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 Did this solve the postmasters gone wild high CPU usage issue for you?
I modified max connections directly in postgresql.conf (/var/discourse/shared/standalone/postgres_data/postgresql.conf) and used ./launcher rebuild app. Haven’t noticed a difference though.
I tried giving postgres more memory and less. Adding swap seemed to have helped (hence trying giving pg less memory) . One thing that I did that might have helped was to backup and restore the database. Or it could be that it did nothing.
I don’t have a silver bullet, but those are the things that I did.
Ça commence aussi à m’arriver depuis que j’ai installé la mise à jour vers la version 2.5.0.beta5. Un par un, je vois apparaître davantage de processus postmaster qui utilisent autant de CPU que possible, et il leur faut parfois plusieurs minutes pour se terminer. Progressivement, cela épuise tous les crédits AWS du serveur et rend l’ensemble du forum lent, voire inutilisable.
Augmenter max_connections n’a eu aucun effet, tout comme la reconstruction de l’application.
Avant de passer à la version 2.5.0.beta5, je n’avais jamais observé ce problème. Auriez-vous une piste sur ce que je devrais examiner ?
Nous avons mis à jour notre forum vers la version 2.5.0.beta5 hier, et depuis, il est lent et ne répond plus. Plusieurs tâches du postmaster se situent tout en haut de la liste et consomment 90 à 100 % du processeur. Cela provoque des délais d’attente sur de nombreuses parties du forum, qui renvoie une erreur 502 aux utilisateurs.
Les tâches apparaissent et disparaissent, mais tant qu’elles sont actives, le forum est peu utilisable.
Ces étapes ne correspondent-elles pas à la finalisation de la mise à niveau de Postgres 12 ? Je pense qu’il doit effectuer un nettoyage interne après la migration de PG10 vers PG12. Cette situation persiste-t-elle pendant un jour ou plus ?
Par ailleurs, pour confirmer : je suis bien passé de la page 10 à la page 12 (je sais que l’on peut rester sur la page 10 si on le souhaite, je voulais simplement clarifier ce point).
Je ne sais pas si cela est pertinent, mais la navigation vers le résumé d’un utilisateur fait systématiquement grimper l’utilisation du processeur à plus de 90 %, ce qui se termine toujours par une erreur 502. Les autres sections du profil semblent fonctionner, bien que lentement.
Je vais surveiller la situation au cours de la journée pour voir si les choses se règlent d’elles-mêmes, et je tiendrai à jour cette discussion.
Il se peut qu’un nettoyage soit nécessaire après la migration. Si vous consultez le sujet officiel de mise à niveau ici et que vous lisez attentivement le premier message, vous y trouverez des détails et des étapes recommandées – PostgreSQL 12 update
Merci à @codinghorror et @markersocial pour les instructions. Cela fait maintenant plus d’une journée et tout semble être revenu à la normale. Je n’ai rien fait d’autre qu’attendre.
Je vais surveiller la situation pour voir si d’autres erreurs 502 apparaissent (cela pourrait être dû à un faible nombre d’utilisateurs pendant les heures creuses).
Si cela se reproduit, j’essaierai les étapes que vous avez listées.
