Hi all, I have turned vm.overcommit_memory on 1.
It's a pretty much dedicated machine anyway, except for some postgres maintainance scripts I run in python / bash from the server. We'll see what it gives. cheers, Bert On Wed, Apr 3, 2013 at 8:45 AM, Bert <bier...@gmail.com> wrote: > Hi Tom, > > thanks for the tip! it was indeed the oom killer. > > Is it wise to disable the oom killer? Or will the server really go down > withough postgres doing something about it? > > currently I already lowered the shared_memory value a bit.. > > cheers, > Bert > > > On Tue, Apr 2, 2013 at 8:06 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Bert <bier...@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. >> >> regards, tom lane >> > > > > -- > Bert Desmet > 0477/305361 > -- Bert Desmet 0477/305361
