On Tue, Oct 8, 2019 at 12:44 PM Merlin Moncure <mmonc...@gmail.com> wrote: > On Sun, Apr 14, 2019 at 3:51 PM Gunther <r...@gusw.net> wrote: > > > > For weeks now, I am banging my head at an "out of memory" situation. There > > is only one query I am running on an 8 GB system, whatever I try, I get > > knocked out on this out of memory. It is extremely impenetrable to > > understand and fix this error. I guess I could add a swap file, and then I > > would have to take the penalty of swapping. But how can I actually address > > an out of memory condition if the system doesn't tell me where it is > > happening? > > We can't really see anything too worrisome. There is always lots of memory > > used by cache, which could have been mobilized. The only possible > > explanation I can think of is that in that moment of the crash the memory > > utilization suddenly skyrocketed in less than a second, so that the 2 > > second vmstat interval wouldn't show it??? Nah. > > > > I have already much reduced work_mem, which has helped in some other cases > > before. Now I am going to reduce the shared_buffers now, but that seems > > counter-intuitive because we are sitting on all that cache memory unused! > > > > Might this be a bug? It feels like a bug. It feels like those out of memory > > issues should be handled more gracefully (garbage collection attempt?) and > > that somehow there should be more information so the person can do anything > > about it. > > I kind of agree that nothing according to vmstat suggests you have a > problem. One thing you left out is the precise mechanics of the > failure; is the database getting nuked by the oom killer? Do you have > the logs?
oops, I missed quite a bit of context upthread. sorry for repeat noise. merlin
