On Feb 7, 2008 11:59 PM, Martijn van Oosterhout [EMAIL PROTECTED] wrote:
On Thu, Feb 07, 2008 at 08:22:42PM +0100, Dawid Kuroczko wrote:
Nw, I know work_mem is not total per process limit, but
rather per sort/hash/etc operation. I know the scheme is a bit
sketchy, but I think this
while we are at it -- one feature would be great for 8.4, an
ability to shange shared buffers size on the fly. I expect
it is not trivial, but would help fine-tuning running database.
I think DBA would need to set maximum shared buffers size
along the normal setting.
Shared
On Fri, Feb 08, 2008 at 09:59:37AM +0100, Dawid Kuroczko wrote:
That is true. However it is possible to allocate more than one shared memory
segment. At simplest I would assume that DBA should specify minimum
shared memory size (say, 1GB) and expected maximum (2GB). And that
between minimum
Simon Riggs escribió:
On Fri, 2008-02-08 at 08:45 +0600, Markus Bertheau wrote:
What about allowing shared_buffers to be only greater than it was at
server start and allocating the extra shared_buffers in one or more
additional shm segments?
Sounds possible.
Hmm, but then you have to
On Fri, Feb 08, 2008 at 06:42:07AM +, Simon Riggs wrote:
On Fri, 2008-02-08 at 08:45 +0600, Markus Bertheau wrote:
What about allowing shared_buffers to be only greater than it was at
server start and allocating the extra shared_buffers in one or more
additional shm segments?
On Feb 5, 2008 10:54 PM, Ron Mayer [EMAIL PROTECTED] wrote:
Decibel! wrote:
Yes, this problem goes way beyond OOM. Just try and configure
work_memory aggressively on a server that might see 50 database
connections, and do it in such a way that you won't swap. Good luck.
That sounds like
On Thu, Feb 07, 2008 at 08:22:42PM +0100, Dawid Kuroczko wrote:
Nw, I know work_mem is not total per process limit, but
rather per sort/hash/etc operation. I know the scheme is a bit
sketchy, but I think this would allow more memory-greedy
operations to use memory, while taking in
Martijn van Oosterhout [EMAIL PROTECTED] writes:
On Thu, Feb 07, 2008 at 08:22:42PM +0100, Dawid Kuroczko wrote:
while we are at it -- one feature would be great for 8.4, an
ability to shange shared buffers size on the fly.
Shared memory segments can't be resized... There's not even a
2008/2/8, Tom Lane [EMAIL PROTECTED]:
Martijn van Oosterhout [EMAIL PROTECTED] writes:
On Thu, Feb 07, 2008 at 08:22:42PM +0100, Dawid Kuroczko wrote:
while we are at it -- one feature would be great for 8.4, an
ability to shange shared buffers size on the fly.
Shared memory
On Thu, 2008-02-07 at 20:22 +0100, Dawid Kuroczko wrote:
On Feb 5, 2008 10:54 PM, Ron Mayer [EMAIL PROTECTED] wrote:
Decibel! wrote:
Yes, this problem goes way beyond OOM. Just try and configure
work_memory aggressively on a server that might see 50 database
connections, and do it
On Fri, 2008-02-08 at 08:45 +0600, Markus Bertheau wrote:
What about allowing shared_buffers to be only greater than it was at
server start and allocating the extra shared_buffers in one or more
additional shm segments?
Sounds possible.
--
Simon Riggs
2ndQuadrant
On Thu, 2008-02-07 at 23:59 +0100, Martijn van Oosterhout wrote:
On Thu, Feb 07, 2008 at 08:22:42PM +0100, Dawid Kuroczko wrote:
Nw, I know work_mem is not total per process limit, but
rather per sort/hash/etc operation. I know the scheme is a bit
sketchy, but I think this would allow
On Mon, Feb 04, 2008 at 08:46:26PM +, Simon Riggs wrote:
On Mon, 2008-02-04 at 15:31 -0500, Tom Lane wrote:
I cannot see any way of restricting global memory
consumption that won't hurt performance and flexibility.
We've discussed particular ways of doing this previously and not got
Decibel! wrote:
Yes, this problem goes way beyond OOM. Just try and configure
work_memory aggressively on a server that might see 50 database
connections, and do it in such a way that you won't swap. Good luck.
That sounds like an even broader and more difficult problem
than managing memory.
On Tue, Feb 05, 2008 at 01:54:17PM -0800, Ron Mayer wrote:
Decibel! wrote:
Yes, this problem goes way beyond OOM. Just try and configure
work_memory aggressively on a server that might see 50 database
connections, and do it in such a way that you won't swap. Good luck.
That sounds
On Fri, 2008-02-01 at 19:08 -0500, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
This page
http://linux-mm.org/OOM_Killer
Egad. Whoever thought *this* was a good idea should be taken out
and shot:
The independent memory size of any child (except a kernel thread) is
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
... OOM_Killer
Egad. Whoever thought *this* was a good idea should be taken out
and shot:
If I read this right, http://lkml.org/lkml/2007/2/9/275 even the
shared memory is counted many times (once per child) for the
parent
On Mon, 2008-02-04 at 19:29 +, Simon Riggs wrote:
On Mon, 2008-02-04 at 10:57 -0800, Jeff Davis wrote:
I tried bringing this up on LKML several times (Ron Mayer linked to one
of my posts: http://lkml.org/lkml/2007/2/9/275). If anyone has an inside
connection to the linux developer
On Mon, 2008-02-04 at 10:57 -0800, Jeff Davis wrote:
I tried bringing this up on LKML several times (Ron Mayer linked to one
of my posts: http://lkml.org/lkml/2007/2/9/275). If anyone has an inside
connection to the linux developer community, I suggest that they raise
this issue.
If you
On Fri, 2008-02-01 at 19:08 -0500, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
This page
http://linux-mm.org/OOM_Killer
Egad. Whoever thought *this* was a good idea should be taken out
and shot:
+1
/*
* Processes which fork a lot of child processes are
On Mon, 2008-02-04 at 15:31 -0500, Tom Lane wrote:
I cannot see any way of restricting global memory
consumption that won't hurt performance and flexibility.
We've discussed particular ways of doing this previously and not got
very far, its true. I think we need to separate problem
Ron Mayer [EMAIL PROTECTED] writes:
That shared memory of the children should not be added to the size
of the parent process multiple times regardless of if something's
an essential process or not.Since those bytes are shared, it
seems such bytes should only be added to the badness once,
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2008-02-04 at 11:38 -0800, Jeff Davis wrote:
I am missing something, can you elaborate? What is postgresql doing
wrong?
We make no attempt to limit our overall memory usage. We limit
individual sessions by default, but don't prevent them from
Alvaro Herrera wrote:
Yeah, the only way to improve the OOM problem would be to harass the
Linux developers to tweak badness() so that it considers the postmaster
to be an essential process rather than the one to preferentially kill.
Wouldn't the more general rule that Jeff Davis pointed out
On Mon, 2008-02-04 at 13:40 -0800, Jeff Davis wrote:
Did you read my post on LKML?
Nice post, BTW. I think you should just submit a patch. There was a
similar problem sometime recently with counting mapped files incorrectly
towards the dirty ratio, so your issue has both clear error and
On Mon, 2008-02-04 at 11:38 -0800, Jeff Davis wrote:
On Mon, 2008-02-04 at 19:29 +, Simon Riggs wrote:
On Mon, 2008-02-04 at 10:57 -0800, Jeff Davis wrote:
I tried bringing this up on LKML several times (Ron Mayer linked to one
of my posts: http://lkml.org/lkml/2007/2/9/275). If
Tom Lane wrote:
Frankly, I'm entirely unpersuaded. It will do zilch to improve the OOM
problem, and I cannot see any way of restricting global memory
consumption that won't hurt performance and flexibility.
Yeah, the only way to improve the OOM problem would be to harass the
Linux developers
On Mon, 2008-02-04 at 16:48 -0500, Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
That shared memory of the children should not be added to the size
of the parent process multiple times regardless of if something's
an essential process or not.Since those bytes are shared, it
On Mon, 2008-02-04 at 20:06 +, Simon Riggs wrote:
We make no attempt to limit our overall memory usage. We limit
individual sessions by default, but don't prevent them from increasing
that allocation as they choose. We don't try to reallocate memory once
it has finished being used.
Did
On Mon, 2008-02-04 at 13:31 -0800, Ron Mayer wrote:
Alvaro Herrera wrote:
Yeah, the only way to improve the OOM problem would be to harass the
Linux developers to tweak badness() so that it considers the postmaster
to be an essential process rather than the one to preferentially kill.
On Sat, Feb 02, 2008 at 09:49:05PM +0100, Florian G. Pflug wrote:
AFAICS, memory overcommit helps if a program creates 50mb of mosty
read-only data, and than forks 10 times, or if it maps a large amount of
memory but writes to that block only sparsely. Since postgres does
neither, a dedicated
Martijn van Oosterhout wrote:
On Sat, Feb 02, 2008 at 09:49:05PM +0100, Florian G. Pflug wrote:
AFAICS, memory overcommit helps if a program creates 50mb of mosty
read-only data, and than forks 10 times, or if it maps a large amount of
memory but writes to that block only sparsely. Since
Martijn van Oosterhout [EMAIL PROTECTED] writes:
On Sat, Feb 02, 2008 at 09:49:05PM +0100, Florian G. Pflug wrote:
AFAICS, memory overcommit helps if a program creates 50mb of mosty
read-only data, and than forks 10 times, or if it maps a large amount of
memory but writes to that block only
Martijn van Oosterhout [EMAIL PROTECTED] writes:
Now, postgres almost certainly will never change much of it so it's not
a big deal, but it could if it wanted to and that what overcommit was
designed for: banking on the fact that 99% of the time, that space
isn't written to. Overcommit is
* Alvaro Herrera:
I am wondering if we can set the system up so that it skips postmaster,
bgwriter etc, and feels more preference towards normal backends (but
then, we would try to give them less points than other regular
processes). That could make the system more robust overall, even if
Florian Weimer [EMAIL PROTECTED] writes:
* Alvaro Herrera:
I am wondering if we can set the system up so that it skips postmaster,
How much does that help? Postmaster c still need to be shut down
when a regular backend dies due to SIGKILL.
The $64 problem is that if the parent postmaster
* Tom Lane:
How much does that help? Postmaster c still need to be shut down
when a regular backend dies due to SIGKILL.
The $64 problem is that if the parent postmaster process is victimized
by the OOM killer, you won't get an automatic restart.
The classic answer to that is to put it
Florian Weimer [EMAIL PROTECTED] writes:
* Tom Lane:
The $64 problem is that if the parent postmaster process is victimized
by the OOM killer, you won't get an automatic restart.
The classic answer to that is to put it into inittab. 8-/
Except that no standard services are actually run that
Tom Lane wrote:
Florian Weimer [EMAIL PROTECTED] writes:
* Alvaro Herrera:
I am wondering if we can set the system up so that it skips postmaster,
How much does that help? Postmaster c still need to be shut down
when a regular backend dies due to SIGKILL.
The $64 problem is that if the
* Tom Lane:
IIRC, the idea is to get the machine out of OOM land with one killed
process, even if it causes dependent processes to fail.
You're just parroting the reasoning given on the cited webpage, which
is loony because it takes no account whatsoever of actual practice.
Oops, I hadn't
Florian G. Pflug wrote:
Maybe we should just react equally brute-force, and just disable the
OOM-Killer for the postmaster if we're running on linux. It seems that
something like echo -17 /proc/pid/oom_adj should do the trick.
That will protect the postmaster but none of the children.
Andrew Dunstan [EMAIL PROTECTED] writes:
Florian G. Pflug wrote:
Maybe we should just react equally brute-force, and just disable the
OOM-Killer for the postmaster if we're running on linux. It seems that
something like echo -17 /proc/pid/oom_adj should do the trick.
That will protect the
Tom Lane wrote:
Another thought is to tell people to run the postmaster under a
per-process memory ulimit that is conservative enough so that the
system can't get into the regime where the OOM killer activates.
ulimit actually behaves the way we want, ie, it's polite about
telling you you
Hi,
Le Saturday 02 February 2008 20:39:15 Florian Weimer, vous avez écrit :
Oops, I hadn't actually read it (I can't reach the Web from this
terminal).
I had a friend in the same situation as you seem to be in and implemented a
mail bot for him to somewhat access documents on the www:
This page
http://linux-mm.org/OOM_Killer
says that you can hint the OOM killer to be more deferential towards
certain processes.
I am wondering if we can set the system up so that it skips postmaster,
bgwriter etc, and feels more preference towards normal backends (but
then, we would try to
Alvaro Herrera [EMAIL PROTECTED] writes:
This page
http://linux-mm.org/OOM_Killer
Egad. Whoever thought *this* was a good idea should be taken out
and shot:
The independent memory size of any child (except a kernel thread) is added
to the score:
/*
* Processes which
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
This page
http://linux-mm.org/OOM_Killer
Egad. Whoever thought *this* was a good idea should be taken out
and shot:
The independent memory size of any child (except a kernel thread) is added
to the score:
/*
47 matches
Mail list logo
