On Fri, Jun 13, 2003 at 12:41:28PM -0400, Bruce Momjian wrote:
> Of course, if you exceed swap, your system hangs.
Are you sure? I ran out of swap once or came damn close, due to a cron
job gone amuck. My clue was starting to see lots of memory allocation
errors. After I fixed what was blocking a
On Thu, Jun 12, 2003 at 10:10:02PM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> It is bad to hang the system, but if it reports swap failure, at least
> the admin knows why it failed, rather than killing random processes.
I wonder if it might be better to suspend whatever process is trying to
t; <[EMAIL PROTECTED]>
Cc: "Kurt Roeckx" <[EMAIL PROTECTED]>; "Matthew Kirkwood"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, June 14, 2003 5:39 PM
Subject: Re: [HACKERS] Pre-allocation of shared memory ...
> I know he does - *but* I think i
On 14 Jun 2003 at 16:38, Andrew Dunstan wrote:
> Summary: don't take shortcuts looking for this - Read the Source, Luke. It's
> important not to give people false expectations. For now, I'm leaning in
> Tom's direction of advising people to avoid Linux for mission-critical
> situations that could r
On Saturday 14 June 2003 16:38, Andrew Dunstan wrote:
> IOW, simply the presence of /proc/sys/vm/overcommit_memory with a value set
> to 0 doesn't guarantee you won't get an OOM kill, AFAICS.
Right. You need the value to be 2 or 3. Which means you need Alan's patch to
do that.
> I *know* the l
ct inode)) >>
PAGE_SHIFT;
return free > pages;
}
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Andrew Dunstan" <[EMAIL PROTECTED]>
Cc: "Kurt Roeckx" <[EMAIL PROTECTED]>; "Matthew Kirkwood"
<[EMA
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> I *know* the latest RH kernel docs *say* they have paranoid mode that
> supposedly guarantees against OOM - it was me that pointed that out
> originally :-). I just checked on the latest sources (today it's RH8, kernel
> 2.4.20-18.8) to be doubly sure,
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> I *know* the latest RH kernel docs *say* they have paranoid mode that
> supposedly guarantees against OOM - it was me that pointed that out
> originally :-). I just checked on the latest sources (today it's RH8, kernel
> 2.4.20-18.8) to be doubly sure,
D]>
To: "Matthew Kirkwood" <[EMAIL PROTECTED]>
Cc: "Andrew Dunstan" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, June 14, 2003 3:44 PM
Subject: Re: [HACKERS] Pre-allocation of shared memory ...
> On Sat, Jun 14, 2003 at 08:32:40PM +0100, Matthew Kirk
On Sat, 14 Jun 2003, Kurt Roeckx wrote:
> > $ ls -l /proc/sys/vm/overcommit_memory
> > -rw-r--r--1 root root0 Jun 14 18:58
> > /proc/sys/vm/overcommit_memory
> > $ uname -a
> > Linux stinky.hoopy.net 2.4.20-20.1.1995.2.2.nptl #1 Fri May 23 12:18:31 EDT 2003
> > i686 i686 i386
On Sat, Jun 14, 2003 at 08:32:40PM +0100, Matthew Kirkwood wrote:
> On Sat, 14 Jun 2003, Andrew Dunstan wrote:
>
> > The trouble with this advice is that if I am an SA wanting to run a
> > DBMS server, I will want to run a kernel supplied by a vendor, not an
> > arbitrary kernel released by a deve
On Sat, 14 Jun 2003, Andrew Dunstan wrote:
> The trouble with this advice is that if I am an SA wanting to run a
> DBMS server, I will want to run a kernel supplied by a vendor, not an
> arbitrary kernel released by a developer, even one as respected as
> Alan Cox.
Like, say, Red Hat:
$ ls -l /p
From: "Andrew Dunstan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, June 14, 2003 12:30 PM
Subject: Re: [HACKERS] Pre-allocation of shared memory ...
> The trouble with this advice is that if I am an SA wanting to run a DBMS
> server, I will want to run a ke
ROTECTED]>
To: "Nigel J. Andrews" <[EMAIL PROTECTED]>
Cc: "Josh Berkus" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, June 14, 2003 11:52 AM
Subject: Re: [HACKERS] Pre-allocation of shared memory ...
> On Friday 13 June 2003 15:29, Lamar Owen
On Friday 13 June 2003 15:29, Lamar Owen wrote:
> It is or was a Linux kernel problem. The 2.2 kernel required double swap
> space, even though it wasn't well documented. Early 2.4 kernels also
> required double swap space, and it was better documented. Current Red Hat
> 2.4 kernels, I'm not sur
On Friday 13 June 2003 12:46, Nigel J. Andrews wrote:
> On Fri, 13 Jun 2003, Lamar Owen wrote:
> > Incidentally, Red Hat as of about 7.0 began insisting on swap space at
> > least as large as twice RAM size. In my case on my 512MB RAM notebook,
> > that meant it wanted 1GB swap. If you upgrade yo
On Fri, Jun 13, 2003 at 12:32:24PM -0400, Lamar Owen wrote:
>
> Incidentally, Red Hat as of about 7.0 began insisting on swap space at least
> as large as twice RAM size. In my case on my 512MB RAM notebook, that meant
> it wanted 1GB swap. If you upgrade your RAM you could get into trouble.
I will say I do use swap sometimes when I am editing a huge image or
something --- there are peak times when it is required.
---
Nigel J. Andrews wrote:
> On Fri, 13 Jun 2003, Lamar Owen wrote:
>
> > On Friday 13 June 2003
On Fri, 13 Jun 2003, Lamar Owen wrote:
> On Friday 13 June 2003 11:55, Josh Berkus wrote:
> > Regrettably, few of the GUI installers for Linux (SuSE or Red Hat, for
> > example), include adequate swap space in their "suggested" disk formatting.
> > Some versions of some distributions do not create
Lamar Owen wrote:
> On Friday 13 June 2003 11:55, Josh Berkus wrote:
> > Regrettably, few of the GUI installers for Linux (SuSE or Red Hat, for
> > example), include adequate swap space in their "suggested" disk formatting.
> > Some versions of some distributions do not create a swap partition at a
On Friday 13 June 2003 11:55, Josh Berkus wrote:
> Regrettably, few of the GUI installers for Linux (SuSE or Red Hat, for
> example), include adequate swap space in their "suggested" disk formatting.
> Some versions of some distributions do not create a swap partition at all;
> others allocate only
Josh Berkus wrote:
> Tom, et al,
>
> > > Given that swap space is cheap, and that killing random processes is
> > > obviously bad, it's not apparent to me why people think this is not
> > > a good approach --- at least for high-reliability servers. And Linux
> > > would definitely like to think o
Tom, et al,
> > Given that swap space is cheap, and that killing random processes is
> > obviously bad, it's not apparent to me why people think this is not
> > a good approach --- at least for high-reliability servers. And Linux
> > would definitely like to think of itself as a server-grade OS.
On Fri, Jun 13, 2003 at 09:25:49AM -0400, Bruce Momjian wrote:
>
> malloc() - should fail right away if it can't reserve the requested
> memory; assuming application request memory they don't use just seems
> dumb --- fix the bad apps.
>
> fork() - this is the tricky one because you don't know a
Patrick Welche wrote:
> On Thu, Jun 12, 2003 at 10:10:02PM -0400, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > > You have to love that swap + 1/2 ram option --- when you need four
> > > > possible options, there is something wrong with your approach
On Thu, Jun 12, 2003 at 10:10:02PM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > You have to love that swap + 1/2 ram option --- when you need four
> > > possible options, there is something wrong with your approach. :-)
> >
> > I'm still wonder
Shridhar Daithankar wrote:
> On 12 Jun 2003 at 11:31, Bruce Momjian wrote:
>
> >
> > OK, doc patch attached and applied. Improvements?
>
> Can we point people to /usr/src/linux/doc...place where they can find more
> documentation and if their kernel supports it or not.
Yes, we could, but the
On Thu, Jun 12, 2003 at 07:22:14PM -0700, Ron Mayer wrote:
> I'm guessing any database backend (postgres, oracle)
> that wasn't part of a long-lived connection seems like
> an especially attractive target to this algorithm.
Yeah, IIRC it tries to pick daemons that can be restarted, or will be
On 12 Jun 2003 at 11:31, Bruce Momjian wrote:
>
> OK, doc patch attached and applied. Improvements?
Can we point people to /usr/src/linux/doc...place where they can find more
documentation and if their kernel supports it or not.
Bye
Shridhar
--
Zall's Laws:(1) Any time you get a mouthf
On Thu, Jun 12, 2003 at 07:22:14PM -0700, Ron Mayer wrote:
> FWIW, you can browse the logic linux uses to choose
> which process to kill here:
> http://lxr.linux.no/source/mm/oom_kill.c
Hey, this LXR thing is cool. It'd be nice to have one of those for
Postgres.
--
Alvaro Herrera ()
"La nat
Jeroen T. Vermeulen wrote:
>
>After that, where do you go? Try to find a reasonable process to shoot
>in the head. From what I heard, although I haven't kept current, a lot
>of work went into selecting a "reasonable" process, so there will be some
>determinism.
FWIW, you can browse the logic li
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I see no reason RAM can't be used as backing store for possible
> copy-on-write use.
Depends on the scenario. For a database like postgres it would work fairly
well since that RAM is still available for filesystem buffers. For Oracle it
would suck becau
Greg Stark wrote:
> I suspect this was less of an issue in the days before copy on write because
> vfork was more widely used/implemented. I'm not sure linux even implements
> vfork other than just as a wrapper around fork. Even BSD ditched it a while
> back though I think I saw that NetBSD reimple
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > You have to love that swap + 1/2 ram option --- when you need four
> > possible options, there is something wrong with your approach. :-)
>
> I'm still wondering what the "no overcommit handling" option does,
> exactly.
I assume it
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Thu, Jun 12, 2003 at 09:18:33PM -0400, Tom Lane wrote:
>
> > Given that swap space is cheap, and that killing random processes is
> > obviously bad, it's not apparent to me why people think this is not
> > a good approach --- at least for high-relia
Bruce Momjian <[EMAIL PROTECTED]> writes:
> You have to love that swap + 1/2 ram option --- when you need four
> possible options, there is something wrong with your approach. :-)
I'm still wondering what the "no overcommit handling" option does,
exactly.
regards, tom lan
Tom Lane wrote:
> "Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> > Given the right allocation proportions, this may mean that in the end the
> > kernel has no way to handle a shortage gracefully by causing fork() or
> > allocations to fail.
>
> Sure it does. All you need is a conservative al
On Thu, Jun 12, 2003 at 09:18:33PM -0400, Tom Lane wrote:
> Given that swap space is cheap, and that killing random processes is
> obviously bad, it's not apparent to me why people think this is not
> a good approach --- at least for high-reliability servers. And Linux
> would definitely like to
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> Given the right allocation proportions, this may mean that in the end the
> kernel has no way to handle a shortage gracefully by causing fork() or
> allocations to fail.
Sure it does. All you need is a conservative allocation policy: fork()
fail
sophical stuff for another day :-)
cheers
andrew
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Greg Stark" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, June 12, 2003 6:19 PM
Subject: Re: [HACKERS] Pre-allocation of shar
On Thu, Jun 12, 2003 at 08:08:28PM -0400, Bruce Momjian wrote:
> >
> > I'm unconvinced, because I've only ever heard of the problem affecting
> > Postgres on Linux.
>
> What I don't understand is why they just don't start failing on
> fork/malloc rather than killing things.
I may be way off the
Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > I think you'll find this overcommit issue affects many if not most Unixen.
>
> I'm unconvinced, because I've only ever heard of the problem affecting
> Postgres on Linux.
What I don't understand is why they just don't start failing on
f
Greg Stark <[EMAIL PROTECTED]> writes:
> I think you'll find this overcommit issue affects many if not most Unixen.
I'm unconvinced, because I've only ever heard of the problem affecting
Postgres on Linux.
regards, tom lane
---(end of broadcast)---
Tom Lane <[EMAIL PROTECTED]> writes:
> The policy they're calling "paranoid overcommit" (don't allocate more
> virtual memory than you have swap) is as far as I know the standard on
> all Unixen other than Linux; certainly it's the traditional behavior.
Uhm, it's traditional for Unixen without ex
Well, let's see what feedback we get.
---
Andrew Dunstan wrote:
>
> A couple of points:
>
> . It is probably a good idea to put do this via /etc/sysctl.conf, which will
> be called earlyish by init scripts (on RH9 it is in
A couple of points:
. It is probably a good idea to put do this via /etc/sysctl.conf, which will
be called earlyish by init scripts (on RH9 it is in the network startup
file, for some reason).
. The setting is not available on all kernel versions AFAIK. The admin needs
to check the docs. I have
OK, new text is:
Linux has poor default memory overcommit behavior. Rather than
failing if it can not reserve enough memory, it returns success,
but later fails when the memory can't be mapped and terminates
the application with kill -9. To prevent unpred
I have added the following sentence to the docs too:
Note, you will need enough swap space to cover all your memory
needs.
I still wish Linux would just fail the fork/malloc when memory is low,
rather than requiring swap for everything _or_ overcommitting. I wonder
if making a u
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, doc patch attached and applied. Improvements?
I think it would be worth spending another sentence to tell people
exactly what the symptom looks like, ie, backends dying with signal 9.
regards, tom lane
-
OK, doc patch attached and applied. Improvements?
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > What really kills [:-)] me is that they allocate memory assuming I will
> > not be using it all, then ter
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What really kills [:-)] me is that they allocate memory assuming I will
> not be using it all, then terminate the executable in an unrecoverable
> way when I go to use the memory.
To be fair, I'm probably misstating things by referring to malloc().
The b
What really kills [:-)] me is that they allocate memory assuming I will
not be using it all, then terminate the executable in an unrecoverable
way when I go to use the memory.
And, they make a judgement on users who don't want this by calling them
"paranoid".
I will add something to the docs abo
Tom Lane wrote:
> [snip]
The
setting now called "paranoid overcommit" is IMHO the *only* acceptable
one for any sort of server system. With anything else, you risk having
critical userspace daemons killed through no fault of their own.
Wow. Thanks for the info. I found the documentation you are
Jon Lapham <[EMAIL PROTECTED]> writes:
> Just curious. What would a rationally designed OS do in an out of
> memory situation?
Fail malloc() requests.
The sysctl docs that Andrew Dunstan just provided give some insight into
the problem: the default behavior of Linux is to promise more virtual
m
Tom Lane wrote:
Is this a Linux machine? If so, the true explanation is probably (c):
the kernel is kill 9'ing randomly-chosen database processes whenever
it starts to feel low on memory. I would suggest checking the
postmaster log to determine the signal number the failed backends are
dying with
On this machine (RH9, kernel 2.4.20-18.9) the docs say (in
/usr/src/linux-2.4/Documentation/vm/overcommit-accounting ):
-
The Linux kernel supports four overcommit handling modes
0 - Heuristic overcommit handling. Obvious overcommits of
address space a
> Yeah, I see it in the Mandrake kernel. But it's not in stock 2.4.19, so
> you can't assume everybody has it.
>
We had this problem on a recent version of good old Slackware.
I think we also had it on RedHat 8 or so.
Doing this kind of killing is definitely a bad habit. I thought it had
it had t
On Wed, Jun 11, 2003 at 07:35:20PM -0400, Doug McNaught wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > Is there no sysctl way to disable such kills?
>
> The -ac kernel patches from Alan Cox have a sysctl to control memory
> overcommit--you can set it to track memory usage and fail alloc
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
> > AFAIK the only good way around this problem is to use another OS with a
> > more rational design for handling low-memory situations. No other Unix
> > does anything remotely as brain-dead as what Linux does. Or bug your
> > favorite
Tom Lane wrote:
> =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> > I have two explanations for the following behaviour:
> > a. a bug
> > b. not enough shared memory
>
> > WARNING: Message from PostgreSQL backend:
> > The Postmaster has informed me that some other backe
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> I have two explanations for the following behaviour:
> a. a bug
> b. not enough shared memory
> WARNING: Message from PostgreSQL backend:
> The Postmaster has informed me that some other backend
> died abnormally a
Bruce Momjian wrote:
We already pre-allocate all shared memory and resources on postmaster
start.
I guess we allocate memory when a backend starts, don't we?
Or do we allocate when the instance starts?
I have two explanations for the following behaviour:
a. a bug
b. not enough shared memory
WARN
We already pre-allocate all shared memory and resources on postmaster
start.
---
Hans-Jürgen Schönig wrote:
> There is a problem which occurs from time to time and which is a bit
> nasty in business environments.
> When the
There is a problem which occurs from time to time and which is a bit
nasty in business environments.
When the shared memory is eaten up by some application such as Apache
PostgreSQL will refuse to do what it should do because there is no
memory around. To many people this looks like a problem re
64 matches
Mail list logo
