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"
Entschuldigung, dass ich einen alten Thread aufwärme.
@pfaffman Hat dies für dich das Problem mit der hohen CPU-Auslastung des Postmasters gelöst?
Ich habe die maximale Anzahl der Verbindungen direkt in der postgresql.conf (/var/discourse/shared/standalone/postgres_data/postgresql.conf) geändert und ./launcher rebuild app ausgeführt. Allerdings habe ich keinen Unterschied bemerkt.
Ich habe versucht, PostgreSQL mehr und weniger Arbeitsspeicher zuzuweisen. Das Hinzufügen von Swap-Speicher scheint geholfen zu haben (daher der Versuch, PostgreSQL weniger Arbeitsspeicher zu geben). Eine Sache, die ich getan habe und die vielleicht geholfen hat, war das Sichern und Wiederherstellen der Datenbank. Oder es könnte sein, dass es nichts bewirkt hat.
Ich habe keine Wunderwaffe, aber das sind die Dinge, die ich getan habe.
Bei mir tritt das jetzt auch auf, nachdem ich das Update auf 2.5.0.beta5 installiert habe. Nach und nach vermehren sich die postmaster-Prozesse, die so viel CPU-Leistung wie möglich beanspruchen, und manchmal dauert es mehrere Minuten, bis sie abgeschlossen sind. Allmählich werden dadurch alle AWS-Guthaben für den Server aufgebraucht, und das gesamte Forum wird träge oder sogar unbrauchbar.
Das Erhöhen von max_connections hatte keine Wirkung, genauso wenig wie das Neuaufbauen der Anwendung.
Bevor ich auf 2.5.0.beta5 aktualisiert habe, habe ich das noch nie gesehen. Haben Sie einen Hinweis, wo ich suchen sollte?
Wir haben unser Forum gestern auf 2.5.0.beta5 aktualisiert, und seitdem ist es langsam und reagiert nicht mehr richtig. Direkt oben laufen einige Postmaster-Jobs, die 90–100 % der CPU-Leistung beanspruchen. Das führt dazu, dass viele Bereiche des Forums timen outen und den Nutzern eine 502-Fehlermeldung anzeigen.
Die Jobs kommen und gehen, aber solange sie aktiv sind, ist das Forum kaum nutzbar.
Wären das nicht die Finalisierungsschritte beim Upgrade auf Postgres 12? Ich glaube, es muss nach der Migration von PG10 auf PG12 noch einige interne Bereinigungen durchführen. Besteht die Situation einen Tag oder länger?
Zur Bestätigung: Ich bin von PG 10 auf 12 gewechselt (ich weiß, dass man optional bei 10 bleiben kann, wollte das nur klarstellen).
Ich bin mir nicht sicher, ob dies relevant ist, aber beim Aufruf der Benutzerzusammenfassung schießt die CPU-Auslastung konsequent auf über 90 % und endet immer mit einem 502-Fehler. Die anderen Bereiche des Profils scheinen zu funktionieren, wenn auch langsam.
Ich werde den Rest des Tages über die Entwicklungen wachen, um zu sehen, ob sich die Dinge von selbst korrigieren, und werde hier aktualisieren.
Es könnte sein, dass nach der Migration eine Bereinigung erforderlich ist. Wenn Sie das offizielle Upgrade-Thema hier überprüfen und den ersten Beitrag genau lesen, finden Sie dort Details und empfohlene Schritte – PostgreSQL 12 update
Danke an @codinghorror und @markersocial für die Anweisungen. Es ist jetzt über einen Tag her und es sieht so aus, als wären die Dinge wieder normal. Ich habe nichts anderes getan als zu warten.
Ich werde die Dinge im Auge behalten und sehen, ob weitere 502-Fehler auftreten (das könnte auf eine geringe Nutzerzahl außerhalb der Hauptverkehrszeiten zurückzuführen sein).
Sollte es erneut auftreten, werde ich die von Ihnen aufgeführten Schritte ausprobieren.
