Pokud správně čtu výstup vašeho topu, není pořízen v okamžiku, kdy vám dochází paměť.
Skutečná chyba se zdá být v pořádku – nepožaduje velké množství paměti, takže v tom okamžiku měl počítač pravděpodobně nedostatek paměti.
Pojďme se rychle podívat na vaše nastavení:
max_connections = 1000 # (change requires restart)
work_mem = 40MB # min 64kB
Takže - jste toho názoru, že můžete podporovat 1000 souběžných dotazů, každý pomocí řekněme 10 + 40 MB (některé mohou používat násobky 40 MB, ale buďme rozumní). Takže - to mi naznačuje, že váš počítač má> 500 jader a řekněme 100 GB RAM. Není tomu tak.
Takže - vezměte svůj počet jader a zdvojnásobte ho - to je rozumná hodnota pro maximální počet připojení. To vám umožní jeden dotaz na každé jádro, zatímco další čeká na I/O. Pak v případě potřeby umístěte před DB pooler připojení (pgbouncer / Java's connection pooling).
Pak můžete dokonce zvážit zvýšení work_mem, pokud budete potřebovat.
Oh - naprosto rozumné běžet bez povoleného swapu. Jakmile začnete swapovat, jste ve světě bolesti, pokud jde o používání databáze.
Upravit:rozbalte work_mem vs shared
V případě pochybností se vždy podívejte na dokumentace .
shared_buffers hodnota je, jak název napovídá sdílená mezi backendy. work_mem není pouze na backend, je to ve skutečnosti na řazení. Takže – jeden dotaz může použít trojnásobek nebo čtyřnásobek této částky, pokud provádí řazení na třech poddotazech.