Re: slave restarts with kill -9 coming from somewhere, or nowhere

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 <biertie(at)gmail(dot)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 <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Bert <biertie(at)gmail(dot)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