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
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 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 mini
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
> > 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.
>
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 woul
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 http://www.2ndQuadra
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
> > > connecti
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".
>
> > Sha
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 e
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 co
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
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
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 memo
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 n
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, i
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
similar
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.
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 on
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.
>
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 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 identifica
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 develope
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
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/2
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 develo
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 y
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 proc
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 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 thre
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
"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 bl
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 po
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 dedicat
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:
http
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 can'
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//oom_adj" should do the trick.
> That will pr
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//oom_adj" should do the trick.
That will protect the postmaster but none of the children. An
* 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 ha
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
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 ru
* 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
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 postma
* 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
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:
/*
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
46 matches
Mail list logo
