this is strange: one connection almost killed the server. So not a combination of a lot of connections. I saw one connection grewing till over 100GB. Then I cancelled the connection before the oom killer became active again.
These are my memory settings: shared_buffers = 20GB temp_buffers = 1GB max_prepared_transactions = 10 work_mem = 4GB maintenance_work_mem = 1GB max_stack_depth = 8MB wal_buffers = 32MB effective_cache_size = 88GB
The server has 128GB ram
How is it possible that one connection (query) uses all the ram? And how can I avoid it?
ps: the database is a DWH. I don't need a lot of connections. But I want to process a lot of data fast.
Bert <biertie@gmail.com> writes: > I'm running the latest postgres version (9.2.3), and today for the first > time I encountered this:
> 12774 2013-04-02 18:13:10 CEST LOG: server process (PID 28463) was > terminated by signal 9: Killed
AFAIK there are only two possible sources of signal 9: a manual kill, or the Linux kernel's OOM killer. If it's the latter there should be a concurrent entry in the kernel logfiles about this. If you find one, suggest reading up on how to disable OOM kills, or at least reconfigure your system to make them less probable.
