From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | dorian dorian <dorian37076(at)yahoo(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: icps, shmmax and shmall - Shared Memory tuning |
Date: | 2002-04-28 20:24:19 |
Message-ID: | 11874.1020025459@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
dorian dorian <dorian37076(at)yahoo(dot)com> writes:
> This was also in the logs -
> Apr 26 09:34:17 mito kernel: Out of Memory: Killed
> process 21540 (postmaster).
Ugh. There's not a lot we can do about the kernel deciding to kill us.
> The machine just stopped responding at 9:34 and had to
> be rebooted. Is there any way to prevent this from
> happening, via a configuration option in postgres?
Perhaps you should talk to the kernel developers about why they can't
find more graceful ways of dealing with out-of-memory situations :-(
I am not sure exactly what Linux considers an out-of-memory situation.
If it's dependent on available swap space, then configuring more swap
would probably prevent this scenario. If only physical RAM counts,
you might need to buy more RAM, or configure Postgres with a smaller
shared_buffers value.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Brent Wood | 2002-04-28 22:03:42 | Re: intel vs amd benchmark for pg server |
Previous Message | Tom Lane | 2002-04-28 20:18:11 | Re: How to track down inconsistent performance? |