From: | Markus Schaber <schabi(at)logix-tt(dot)com> |
---|---|
To: | Richard Troy <rtroy(at)ScienceTools(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Postgres server crash |
Date: | 2006-11-21 13:22:40 |
Message-ID: | 4562FDA0.6060602@logix-tt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi, Richard,
Richard Troy wrote:
> The reason I spent a couple of hours looking for what I could learn on
> this is that I've been absolutely beside myself on this "extremely
> unfortunate" "feature." I had a badly behaving app (but didn't know which
> app it was), so Linux would kill lots of things, like, oh, say, inetd.
Actually, AFAICT, Linux tries to kill the process(es) that use the most
memory ressources first.
Without overcommitment, the OOM killer won't kick in, and as long as the
hoggy applications don't actually exit when malloc fails, they will just
stay around, sitting on their memory.
> Good luck sshing into the box.
SSH'ing into the box will even get worse without overcommitment. When
the machine is stuck, the sshd that tries to spawn its child will get
the out of memory signal, and you won't be able to log in.
HTH,
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS
Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org
From | Date | Subject | |
---|---|---|---|
Next Message | db | 2006-11-21 15:12:47 | Re: BitMapScan performance degradation |
Previous Message | Carlos H. Reimer | 2006-11-21 12:44:23 | RES: Context switching |