Wenn ich die Ausgabe Ihres Top richtig lese, wird sie nicht an einem Punkt aufgenommen, an dem Sie keinen Speicher mehr haben.
Der eigentliche Fehler scheint in Ordnung zu sein - er fordert nicht viel Speicher an, also war vermutlich zu diesem Zeitpunkt nicht genügend Speicher vorhanden.
Werfen wir einen kurzen Blick auf Ihre Einstellungen:
max_connections = 1000 # (change requires restart)
work_mem = 40MB # min 64kB
Sie sind also der Meinung, dass Sie 1000 gleichzeitige Abfragen mit jeweils beispielsweise 10 + 40 MB unterstützen können (einige verwenden möglicherweise ein Vielfaches von 40 MB, aber seien wir vernünftig). Also - das deutet für mich darauf hin, dass Ihr Computer> 500 Kerne hat und sagen wir 100 GB RAM. Das ist nicht der Fall.
Also - nehmen Sie Ihre Anzahl von Kernen und verdoppeln Sie sie - das ist ein vernünftiger Wert für die maximale Anzahl von Verbindungen. Dadurch können Sie jeden Kern abfragen, während ein anderer auf I/O wartet. Platzieren Sie dann bei Bedarf einen Connection Pooler vor der DB (pgbouncer / Javas Connection Pooling).
Dann können Sie ggf. sogar work_mem erhöhen.
Oh - vollkommen vernünftig, ohne aktivierten Swap zu laufen. Sobald Sie mit dem Austauschen beginnen, befinden Sie sich in Bezug auf die Datenbanknutzung sowieso in einer Welt voller Schmerzen.
Bearbeiten:Erweitern Sie work_mem vs shared
Ziehen Sie im Zweifelsfall immer die Dokumentation .
Die shared_buffers Wert wird, wie der Name schon sagt, von Backends gemeinsam genutzt. Das work_mem ist nicht nur pro Backend, es ist tatsächlich pro Sorte. Eine Abfrage kann also drei- oder viermal so viel verbrauchen, wenn sie nach drei Unterabfragen sortiert.
