pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedMax shared_buffers
7+ messages / 6 participants
[nested] [flat]
* Max shared_buffers
@ 2008-04-03 04:56 bitaoxiao <bitaoxiao@gmail.com>
0 siblings, 1 reply; 7+ messages in thread
From: bitaoxiao @ 2008-04-03 04:56 UTC (permalink / raw)
To: pgsql-performance
What can be set as max of postgreSQL shared_buffers and work_mem
2008-04-03
bitaoxiao
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Max shared_buffers
@ 2008-04-03 10:10 sathiya psql <sathiya.psql@gmail.com>
parent: bitaoxiao <bitaoxiao@gmail.com>
0 siblings, 1 reply; 7+ messages in thread
From: sathiya psql @ 2008-04-03 10:10 UTC (permalink / raw)
To: bitaoxiao <bitaoxiao@gmail.com>; +Cc: pgsql-performance
There is NO MAX....
It is according to your hardware you have, and the db you have.
2008/4/3 bitaoxiao <bitaoxiao@gmail.com>:
>
> What can be set as max of postgreSQL shared_buffers and work_mem
>
> 2008-04-03
> ------------------------------
> bitaoxiao
>
>
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Max shared_buffers
@ 2008-04-03 16:49 Scott Marlowe <scott.marlowe@gmail.com>
parent: sathiya psql <sathiya.psql@gmail.com>
0 siblings, 1 reply; 7+ messages in thread
From: Scott Marlowe @ 2008-04-03 16:49 UTC (permalink / raw)
To: sathiya psql <sathiya.psql@gmail.com>; +Cc: bitaoxiao <bitaoxiao@gmail.com>; pgsql-performance
On Thu, Apr 3, 2008 at 4:10 AM, sathiya psql <sathiya.psql@gmail.com> wrote:
> There is NO MAX....
>
> It is according to your hardware you have, and the db you have.
Not entirely true. on 32 bit OS / software, the limit is just under 2
Gig. I'd imagine that the limit on 64 bit hardware / software is
therefore something around 2^63-somesmallnumber which is, for all
practical purposes, unlimited.
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Max shared_buffers
@ 2008-04-03 17:16 Andrej Ricnik-Bay <andrej.groups@gmail.com>
parent: Scott Marlowe <scott.marlowe@gmail.com>
0 siblings, 3 replies; 7+ messages in thread
From: Andrej Ricnik-Bay @ 2008-04-03 17:16 UTC (permalink / raw)
To: Scott Marlowe <scott.marlowe@gmail.com>; +Cc: sathiya psql <sathiya.psql@gmail.com>; bitaoxiao <bitaoxiao@gmail.com>; pgsql-performance
On 04/04/2008, Scott Marlowe <scott.marlowe@gmail.com> wrote:
> Not entirely true. on 32 bit OS / software, the limit is just under 2
> Gig.
Where do you get that figure from?
There's an architectural (theoretical) limitation of RAM at 4GB,
but with the PAE (that pretty much any CPU since the Pentium Pro
offers) one can happily address 64GB on 32-bit.
Or are you talking about some Postgres limitation?
Cheers,
Andrej
--
Please don't top post, and don't use HTML e-Mail :} Make your quotes concise.
http://www.american.edu/econ/notes/htmlmail.htm
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Max shared_buffers
@ 2008-04-03 17:20 Matthew <matthew@flymine.org>
parent: Andrej Ricnik-Bay <andrej.groups@gmail.com>
2 siblings, 0 replies; 7+ messages in thread
From: Matthew @ 2008-04-03 17:20 UTC (permalink / raw)
To: pgsql-performance
On Fri, 4 Apr 2008, Andrej Ricnik-Bay wrote:
> On 04/04/2008, Scott Marlowe <scott.marlowe@gmail.com> wrote:
>> Not entirely true. on 32 bit OS / software, the limit is just under 2
>> Gig.
>
> Or are you talking about some Postgres limitation?
Since the original question was:
> What can be set as max of ¿½postgreS shared_buffers and work_mem?
that would be a "Yes."
Matthew
--
I quite understand I'm doing algebra on the blackboard and the usual response
is to throw objects... If you're going to freak out... wait until party time
and invite me along -- Computer Science Lecturer
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Max shared_buffers
@ 2008-04-03 17:48 Scott Marlowe <scott.marlowe@gmail.com>
parent: Andrej Ricnik-Bay <andrej.groups@gmail.com>
2 siblings, 0 replies; 7+ messages in thread
From: Scott Marlowe @ 2008-04-03 17:48 UTC (permalink / raw)
To: Andrej Ricnik-Bay <andrej.groups@gmail.com>; +Cc: sathiya psql <sathiya.psql@gmail.com>; bitaoxiao <bitaoxiao@gmail.com>; pgsql-performance
On Thu, Apr 3, 2008 at 11:16 AM, Andrej Ricnik-Bay
<andrej.groups@gmail.com> wrote:
> On 04/04/2008, Scott Marlowe <scott.marlowe@gmail.com> wrote:
> > Not entirely true. on 32 bit OS / software, the limit is just under 2
> > Gig.
>
> Where do you get that figure from?
>
> There's an architectural (theoretical) limitation of RAM at 4GB,
> but with the PAE (that pretty much any CPU since the Pentium Pro
> offers) one can happily address 64GB on 32-bit.
>
> Or are you talking about some Postgres limitation?
Note I was talking about running 32 bit postgresql (on either 32 or 64
bit hardware, it doesn't matter) where the limit we've seen in the
perf group over the years has been just under 2G.
I'm extrapolating that on 64 bit hardware, 64 bit postgresql's limit
would be similar, i.e. 2^63-x where x is some small number that keeps
us just under 2^63.
So, experience and reading here for a few years is where I get that
number from. But feel free to test it. It'd be nice to know you
could get >2Gig shared buffer on 32 bit postgresql on some
environment.
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Max shared_buffers
@ 2008-04-03 17:58 Craig Ringer <craig@postnewspapers.com.au>
parent: Andrej Ricnik-Bay <andrej.groups@gmail.com>
2 siblings, 0 replies; 7+ messages in thread
From: Craig Ringer @ 2008-04-03 17:58 UTC (permalink / raw)
To: ; +Cc: pgsql-performance
Andrej Ricnik-Bay wrote:
> On 04/04/2008, Scott Marlowe <scott.marlowe@gmail.com> wrote:
>> Not entirely true. on 32 bit OS / software, the limit is just under 2
>> Gig.
That depends on the OS. On Linux it's AFAIK closer to 3GB because of
less address space being consumed by the kernel, though I think free app
address space might be further reduced with truly *massive* amounts of
RAM. There are patches (the "4GB/4GB" patches) that do dodgy address
space mapping to support a full 4GB application address space.
> Where do you get that figure from?
>
> There's an architectural (theoretical) limitation of RAM at 4GB,
> but with the PAE (that pretty much any CPU since the Pentium Pro
> offers) one can happily address 64GB on 32-bit.
The OS can address more than 4GB of physical RAM with PAE, yes.
However, AFAIK no single process may directly use more than (4GB -
kernel address space requirements) of RAM without using special
extensions like address space windowing. Of course, they still benefit
from the extra RAM indirectly through bigger disk caches, less
competition with other processes for free physical RAM, etc.
As Pg uses a multiprocess model I imagine individual backends can make
use of a large amount of RAM (as work_mem etc), though the address space
consumed by the shared memory will limit how much it can use.
There's a decent, if Microsoft-specific, article about PAE here:
http://www.microsoft.com/whdc/system/platform/server/PAE/pae_os.mspx
--
Craig Ringer
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2008-04-03 17:58 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2008-04-03 04:56 Max shared_buffers bitaoxiao <bitaoxiao@gmail.com>
2008-04-03 10:10 ` sathiya psql <sathiya.psql@gmail.com>
2008-04-03 16:49 ` Scott Marlowe <scott.marlowe@gmail.com>
2008-04-03 17:16 ` Andrej Ricnik-Bay <andrej.groups@gmail.com>
2008-04-03 17:20 ` Matthew <matthew@flymine.org>
2008-04-03 17:48 ` Scott Marlowe <scott.marlowe@gmail.com>
2008-04-03 17:58 ` Craig Ringer <craig@postnewspapers.com.au>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox