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
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
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 run
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 it has probably been wiped out by accident
somewhere along the line (like when they went to 2.4.20
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 sure
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 wrote:
It is or was a Linux kernel problem. The 2.2 kernel required
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 kernel supplied by a vendor, not an arbitrary
kernel
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
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 developer,
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 GNU/Linux
:44 PM
Subject: Re: [HACKERS] Pre-allocation of shared memory ...
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
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, and
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, and
]
Cc: Kurt Roeckx [EMAIL PROTECTED]; Matthew Kirkwood
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Saturday, June 14, 2003 5:16 PM
Subject: Re: [HACKERS] Pre-allocation of shared memory ...
Andrew Dunstan [EMAIL PROTECTED] writes:
I *know* the latest RH kernel docs *say* they have paranoid mode
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
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
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
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 name of
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 wondering what the
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 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 at
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.
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 of itself as a
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 all;
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 a swap
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, 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. In
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 your RAM
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 to
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
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
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
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
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
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 big
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 terminate
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
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
OK, new text is:
para
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 literalkill -9/. To
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
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 the
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
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
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
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 mark
:-)
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 shared memory ...
Greg Stark [EMAIL PROTECTED] writes:
I think you'll find
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()
fails if
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
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 allocation
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 lane
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-reliability
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 does no
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
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 because
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 linux
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
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
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
=?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 and
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 backend
died
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 Linux
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 allocations
62 matches
Mail list logo
