public inbox for [email protected]
help / color / mirror / Atom feedshared_buffers and shmmax
28+ messages / 10 participants
[nested] [flat]
* shared_buffers and shmmax
@ 2008-07-22 13:39 dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
0 siblings, 1 reply; 28+ messages in thread
From: dx k9 @ 2008-07-22 13:39 UTC (permalink / raw)
To: posgres support <[email protected]>
Hi,
I'm trying to understand what the documentation means by bytes per increment, what is the increment supposed to be bytes, MB, or Kb. I have my shared_buffers set to 577 MB(4 instances) and I'm multiplying by 8400 bytes. I would think I would want to keep everything in bytes and not mulitply bytes times MB, but this is what table 17-2 implies. If I convert 577 to bytes and multiply, my calculator goes exponential on me. I'm going through this table and adding up to see what my shmmax should be (it's 7.5 GB) out of a total memory of 16 GB with 1000 max_connections right now. What should I use as the "increment" value in regards to shared buffers, 577, 590848 or 605028352 ?
a) 577 MB (This seems too small)
b) 590,848 Kb (this seems just right)
c) 605,028,352 bytes (this seems too big, I hope it's not c)
Thanks,
~DjK
Table 17-2. Configuration parameters affecting PostgreSQL's shared memory usage
Name
Approximate multiplier (bytes per increment) as of 8.3
max_connections
1800 + 270 * max_locks_per_transaction
autovacuum_max_workers
1800 + 270 * max_locks_per_transaction
max_prepared_transactions
770 + 270 * max_locks_per_transaction
shared_buffers
8400 (assuming 8 kB BLCKSZ)
wal_buffers
8200 (assuming 8 kB XLOG_BLCKSZ)
max_fsm_relations
70
max_fsm_pages
6
Fixed space requirements
770 kB
_________________________________________________________________
Stay in touch when you're away with Windows Live Messenger.
http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_messenger2_072008
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
@ 2008-07-22 14:08 ` Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
0 siblings, 1 reply; 28+ messages in thread
From: Valentin Bogdanov @ 2008-07-22 14:08 UTC (permalink / raw)
To: posgres support <[email protected]>; dx k9 <[email protected]>
shared_buffers is in disk block size, typically 8K, at least that's what it is on Linux platforms. shmmax is quite simply in bytes.
The default shared_buffer of a 1000 is quite conservative. A good starting value is something like 15-25 percent of your main memory or so I am being told. It really depends on how the machine you have your database on is being used. If postgres is the only application using your box then you can even set this to 80% of the memory. You're fine as long as postgres does not have to resort to using the swap space.
If you set shared_buffers so high that it doesn't agree with your systems shmmax then postgres will give you the required value on startup.
Regards,
Val
--- On Tue, 22/7/08, dx k9 <[email protected]> wrote:
> From: dx k9 <[email protected]>
> Subject: [ADMIN] shared_buffers and shmmax
> To: "posgres support" <[email protected]>
> Date: Tuesday, 22 July, 2008, 2:39 PM
> Hi,
> I'm trying to understand what the documentation means
> by bytes per increment, what is the increment supposed to
> be bytes, MB, or Kb. I have my shared_buffers set to 577
> MB(4 instances) and I'm multiplying by 8400 bytes. I
> would think I would want to keep everything in bytes and
> not mulitply bytes times MB, but this is what table 17-2
> implies. If I convert 577 to bytes and multiply, my
> calculator goes exponential on me. I'm going through
> this table and adding up to see what my shmmax should be
> (it's 7.5 GB) out of a total memory of 16 GB with 1000
> max_connections right now. What should I use as the
> "increment" value in regards to shared buffers,
> 577, 590848 or 605028352 ?
>
> a) 577 MB (This seems too small)
> b) 590,848 Kb (this seems just right)
> c) 605,028,352 bytes (this seems too big, I hope it's
> not c)
>
> Thanks,
> ~DjK
>
> Table 17-2. Configuration parameters affecting
> PostgreSQL's shared memory usage
>
>
>
>
>
>
>
> Name
> Approximate multiplier (bytes per increment) as of 8.3
>
>
> max_connections
> 1800 + 270 * max_locks_per_transaction
>
> autovacuum_max_workers
> 1800 + 270 * max_locks_per_transaction
>
> max_prepared_transactions
> 770 + 270 * max_locks_per_transaction
>
> shared_buffers
> 8400 (assuming 8 kB BLCKSZ)
>
> wal_buffers
> 8200 (assuming 8 kB XLOG_BLCKSZ)
>
> max_fsm_relations
> 70
>
> max_fsm_pages
> 6
>
> Fixed space requirements
> 770 kB
> _________________________________________________________________
> Stay in touch when you're away with Windows Live
> Messenger.
> http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_messenger2_072008
__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
@ 2008-07-22 14:45 ` Tom Lane <[email protected]>
2008-07-22 19:30 ` Re: [ADMIN] shared_buffers and shmmax Francisco Reyes <[email protected]>
2008-07-24 17:54 ` Re: [ADMIN] shared_buffers and shmmax Greg Sabino Mullane <[email protected]>
2008-12-15 23:23 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
0 siblings, 3 replies; 28+ messages in thread
From: Tom Lane @ 2008-07-22 14:45 UTC (permalink / raw)
To: [email protected]; +Cc: pgsql-docs; dx k9 <[email protected]>
[ redirecting to pgsql-docs ]
Valentin Bogdanov <[email protected]> writes:
>> From: dx k9 <[email protected]>
>> I'm trying to understand what the documentation means
>> by bytes per increment, what is the increment supposed to
>> be bytes, MB, or Kb.
> shared_buffers is in disk block size, typically 8K, at least that's what it is on Linux platforms. shmmax is quite simply in bytes.
The table the OP is looking at (table 17.2 in the 8.3 docs) predates
the ability to specify shared_buffers in KB or MB instead of
number-of-buffers. I agree it's not entirely obvious that what it
means is "multiply your setting in KB/MB by 8400/8192". Anybody have
an idea how to clarify things?
regards, tom lane
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
@ 2008-07-22 19:30 ` Francisco Reyes <[email protected]>
2 siblings, 0 replies; 28+ messages in thread
From: Francisco Reyes @ 2008-07-22 19:30 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: pgsql-docs; [email protected]; [email protected]
On 10:45 am 07/22/08 Tom Lane <[email protected]> wrote:
> [ redirecting to pgsql-docs ]
> number-of-buffers. I agree it's not entirely obvious that what it
> means is "multiply your setting in KB/MB by 8400/8192". Anybody have
> an idea how to clarify things?
Perhaps changing the table title?
Table 17-2. Configuration parameters affecting PostgreSQL's shared memory
usage when not using a size modified.
Alternatively, below the table we could have clarifications such as:
Previously, it was not possible to indicate a size modified such as M for
Megabytes. As of version X.Y, Postgresql allows to use M, for MB, GB for GB
and more... See.... for all values.
When not using one of the new modifiers the space used would be the number
you enter times the constant on the right side of the table.
For example using 100 shared_buffers would be 100 x 8400 = 840,000 bytes.
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
@ 2008-07-24 17:54 ` Greg Sabino Mullane <[email protected]>
2008-07-24 18:02 ` Re: [DOCS] [ADMIN] shared_buffers and shmmax Joshua D. Drake <[email protected]>
2008-07-26 21:47 ` Re: [ADMIN] shared_buffers and shmmax Greg Smith <[email protected]>
2008-12-15 23:32 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2 siblings, 3 replies; 28+ messages in thread
From: Greg Sabino Mullane @ 2008-07-24 17:54 UTC (permalink / raw)
To: pgsql-docs; +Cc: [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
NotDashEscaped: You need GnuPG to verify this message
>> shared_buffers is in disk block size, typically 8K
> The table the OP is looking at (table 17.2 in the 8.3 docs) predates
> the ability to specify shared_buffers in KB or MB instead of
> number-of-buffers. I agree it's not entirely obvious that what it
> means is "multiply your setting in KB/MB by 8400/8192". Anybody have
> an idea how to clarify things?
Bite the bullet and start showing the buffer settings as a pure number of bytes
everywhere, and get rid of the confusing '8kB' unit in pg_settings? Things like
this don't help our cause:
test=# show shared_buffers;
shared_buffers
----------------
24MB
(1 row)
test=# set temp_buffers = '24MB';
SET
test=# show temp_buffers;
temp_buffers
--------------
3072
test=# select name, setting from pg_settings where name ~ 'buffers';
name | setting
----------------+---------
shared_buffers | 3072
temp_buffers | 3072
wal_buffers | 8
test=# show wal_buffers;
wal_buffers
-------------
64kB
--
Greg Sabino Mullane [email protected]
End Point Corporation
PGP Key: 0x14964AC8 200807241351
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAkiIwYYACgkQvJuQZxSWSsiY5wCfU/tca+1JakWaMCDDRHEHk/Uj
1rcAoMi1FNGSpJhyXWde1psygq6v3MlS
=gCPg
-----END PGP SIGNATURE-----
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [DOCS] [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-07-24 17:54 ` Re: [ADMIN] shared_buffers and shmmax Greg Sabino Mullane <[email protected]>
@ 2008-07-24 18:02 ` Joshua D. Drake <[email protected]>
2 siblings, 0 replies; 28+ messages in thread
From: Joshua D. Drake @ 2008-07-24 18:02 UTC (permalink / raw)
To: Greg Sabino Mullane <[email protected]>; +Cc: pgsql-docs; [email protected]
On Thu, 2008-07-24 at 17:54 +0000, Greg Sabino Mullane wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
> NotDashEscaped: You need GnuPG to verify this message
>
>
> >> shared_buffers is in disk block size, typically 8K
>
> > The table the OP is looking at (table 17.2 in the 8.3 docs) predates
> > the ability to specify shared_buffers in KB or MB instead of
> > number-of-buffers. I agree it's not entirely obvious that what it
> > means is "multiply your setting in KB/MB by 8400/8192". Anybody have
> > an idea how to clarify things?
>
> Bite the bullet and start showing the buffer settings as a pure number of bytes
> everywhere, and get rid of the confusing '8kB' unit in pg_settings?
+1
We have helper functions like pg_size_pretty() to resolve the other
issues.
Joshua D. Drake
--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-07-24 17:54 ` Re: [ADMIN] shared_buffers and shmmax Greg Sabino Mullane <[email protected]>
@ 2008-07-26 21:47 ` Greg Smith <[email protected]>
2008-08-12 17:48 ` Re: [HACKERS] [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2 siblings, 1 reply; 28+ messages in thread
From: Greg Smith @ 2008-07-26 21:47 UTC (permalink / raw)
To: Greg Sabino Mullane <[email protected]>; +Cc: pgsql-docs; [email protected]; [email protected]
On Thu, 24 Jul 2008, Greg Sabino Mullane wrote:
> Bite the bullet and start showing the buffer settings as a pure number of bytes
> everywhere, and get rid of the confusing '8kB' unit in pg_settings?
There's already some changes needed in this area needed to execute the
full GUC cleanup/wizard plan that's being worked on. The pg_settings view
really should show the value both as the user input it and as it's stored
internally for cases like these, which lowers the confusion here a bit
even without going so far as converting everything to bytes.
--
* Greg Smith [email protected] http://www.gregsmith.com Baltimore, MD
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [HACKERS] [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-07-24 17:54 ` Re: [ADMIN] shared_buffers and shmmax Greg Sabino Mullane <[email protected]>
2008-07-26 21:47 ` Re: [ADMIN] shared_buffers and shmmax Greg Smith <[email protected]>
@ 2008-08-12 17:48 ` Bruce Momjian <[email protected]>
2008-08-12 19:43 ` Re: [HACKERS] [ADMIN] shared_buffers and shmmax Greg Smith <[email protected]>
0 siblings, 1 reply; 28+ messages in thread
From: Bruce Momjian @ 2008-08-12 17:48 UTC (permalink / raw)
To: Greg Smith <[email protected]>; +Cc: Greg Sabino Mullane <[email protected]>; pgsql-docs; [email protected]
Greg Smith wrote:
> On Thu, 24 Jul 2008, Greg Sabino Mullane wrote:
>
> > Bite the bullet and start showing the buffer settings as a pure number of bytes
> > everywhere, and get rid of the confusing '8kB' unit in pg_settings?
>
> There's already some changes needed in this area needed to execute the
> full GUC cleanup/wizard plan that's being worked on. The pg_settings view
> really should show the value both as the user input it and as it's stored
> internally for cases like these, which lowers the confusion here a bit
> even without going so far as converting everything to bytes.
Is this a TODO?
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [HACKERS] [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-07-24 17:54 ` Re: [ADMIN] shared_buffers and shmmax Greg Sabino Mullane <[email protected]>
2008-07-26 21:47 ` Re: [ADMIN] shared_buffers and shmmax Greg Smith <[email protected]>
2008-08-12 17:48 ` Re: [HACKERS] [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
@ 2008-08-12 19:43 ` Greg Smith <[email protected]>
2008-08-22 05:49 ` Re: [HACKERS] [ADMIN] shared_buffers and shmmax Decibel! <[email protected]>
0 siblings, 1 reply; 28+ messages in thread
From: Greg Smith @ 2008-08-12 19:43 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Greg Sabino Mullane <[email protected]>; pgsql-docs; [email protected]
On Tue, 12 Aug 2008, Bruce Momjian wrote:
>> There's already some changes needed in this area needed to execute the
>> full GUC cleanup/wizard plan that's being worked on. The pg_settings view
>> really should show the value both as the user input it and as it's stored
>> internally for cases like these, which lowers the confusion here a bit
>> even without going so far as converting everything to bytes.
>
> Is this a TODO?
I don't think you need yet another TODO for every detail, the existing
TODO "Add external tool to auto-tune some postgresql.conf parameters" has
to squash a bunch of issues in this area. This particular issue Greg
raised will already be improved significantly if executing the larger
project plan at http://wiki.postgresql.org/wiki/GUCS_Overhaul
This week Robert Treat and I have been doing a lot of work on "Problem #1"
there, "Most people have no idea how to set [GUCs]" which I know some
people wanted to see a more formal document for before mucking with any of
the code. I'll have something to announce there shortly.
--
* Greg Smith [email protected] http://www.gregsmith.com Baltimore, MD
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [HACKERS] [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-07-24 17:54 ` Re: [ADMIN] shared_buffers and shmmax Greg Sabino Mullane <[email protected]>
2008-07-26 21:47 ` Re: [ADMIN] shared_buffers and shmmax Greg Smith <[email protected]>
2008-08-12 17:48 ` Re: [HACKERS] [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-08-12 19:43 ` Re: [HACKERS] [ADMIN] shared_buffers and shmmax Greg Smith <[email protected]>
@ 2008-08-22 05:49 ` Decibel! <[email protected]>
0 siblings, 0 replies; 28+ messages in thread
From: Decibel! @ 2008-08-22 05:49 UTC (permalink / raw)
To: Greg Smith <[email protected]>; +Cc: Bruce Momjian <[email protected]>; Greg Sabino Mullane <[email protected]>; pgsql-docs; [email protected]
On Aug 12, 2008, at 2:43 PM, Greg Smith wrote:
> On Tue, 12 Aug 2008, Bruce Momjian wrote:
>>> There's already some changes needed in this area needed to
>>> execute the
>>> full GUC cleanup/wizard plan that's being worked on. The
>>> pg_settings view
>>> really should show the value both as the user input it and as
>>> it's stored
>>> internally for cases like these, which lowers the confusion here
>>> a bit
>>> even without going so far as converting everything to bytes.
>>
>> Is this a TODO?
>
> I don't think you need yet another TODO for every detail, the
> existing TODO "Add external tool to auto-tune some postgresql.conf
> parameters" has to squash a bunch of issues in this area. This
> particular issue Greg raised will already be improved significantly
> if executing the larger project plan at http://wiki.postgresql.org/
> wiki/GUCS_Overhaul
Yeah, but OTOH it's not clear at all when we might see such a tool,
while clarifying this stuff would help people immediately... I think
a TODO would be good to make sure this doesn't fall through the cracks.
--
Decibel!, aka Jim C. Nasby, Database Architect [email protected]
Give your computer some brain candy! www.distributed.net Team #1828
Attachments:
[application/pkcs7-signature] smime.p7s (2.5K, 2-smime.p7s)
download
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-07-24 17:54 ` Re: [ADMIN] shared_buffers and shmmax Greg Sabino Mullane <[email protected]>
@ 2008-12-15 23:32 ` Bruce Momjian <[email protected]>
2 siblings, 0 replies; 28+ messages in thread
From: Bruce Momjian @ 2008-12-15 23:32 UTC (permalink / raw)
To: Greg Sabino Mullane <[email protected]>; +Cc: pgsql-docs; [email protected]
I have added this TODO item:
Rationalize the discrepancy between settings that use values in bytes
and SHOW that returns the object count
* http://archives.postgresql.org/pgsql-docs/2008-07/msg00007.php
---------------------------------------------------------------------------
Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
> NotDashEscaped: You need GnuPG to verify this message
>
>
> >> shared_buffers is in disk block size, typically 8K
>
> > The table the OP is looking at (table 17.2 in the 8.3 docs) predates
> > the ability to specify shared_buffers in KB or MB instead of
> > number-of-buffers. I agree it's not entirely obvious that what it
> > means is "multiply your setting in KB/MB by 8400/8192". Anybody have
> > an idea how to clarify things?
>
> Bite the bullet and start showing the buffer settings as a pure number of bytes
> everywhere, and get rid of the confusing '8kB' unit in pg_settings? Things like
> this don't help our cause:
>
> test=# show shared_buffers;
> shared_buffers
> ----------------
> 24MB
> (1 row)
>
> test=# set temp_buffers = '24MB';
> SET
>
> test=# show temp_buffers;
> temp_buffers
> --------------
> 3072
>
> test=# select name, setting from pg_settings where name ~ 'buffers';
> name | setting
> ----------------+---------
> shared_buffers | 3072
> temp_buffers | 3072
> wal_buffers | 8
>
> test=# show wal_buffers;
> wal_buffers
> -------------
> 64kB
>
>
> --
> Greg Sabino Mullane [email protected]
> End Point Corporation
> PGP Key: 0x14964AC8 200807241351
> http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
> -----BEGIN PGP SIGNATURE-----
>
> iEYEAREDAAYFAkiIwYYACgkQvJuQZxSWSsiY5wCfU/tca+1JakWaMCDDRHEHk/Uj
> 1rcAoMi1FNGSpJhyXWde1psygq6v3MlS
> =gCPg
> -----END PGP SIGNATURE-----
>
>
>
> --
> Sent via pgsql-docs mailing list ([email protected])
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-docs
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
@ 2008-12-15 23:23 ` Bruce Momjian <[email protected]>
2008-12-15 23:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2 siblings, 1 reply; 28+ messages in thread
From: Bruce Momjian @ 2008-12-15 23:23 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: [email protected]; pgsql-docs; dx k9 <[email protected]>
Tom Lane wrote:
> [ redirecting to pgsql-docs ]
>
> Valentin Bogdanov <[email protected]> writes:
> >> From: dx k9 <[email protected]>
> >> I'm trying to understand what the documentation means
> >> by bytes per increment, what is the increment supposed to
> >> be bytes, MB, or Kb.
>
> > shared_buffers is in disk block size, typically 8K, at least that's what it is on Linux platforms. shmmax is quite simply in bytes.
>
> The table the OP is looking at (table 17.2 in the 8.3 docs) predates
> the ability to specify shared_buffers in KB or MB instead of
> number-of-buffers. I agree it's not entirely obvious that what it
> means is "multiply your setting in KB/MB by 8400/8192". Anybody have
> an idea how to clarify things?
I have updated the table title to be clearer.
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Attachments:
[text/x-diff] /rtmp/diff (1023B, 2-%2Frtmp%2Fdiff)
download | inline diff:
Index: doc/src/sgml/runtime.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v
retrieving revision 1.422
diff -c -c -r1.422 runtime.sgml
*** doc/src/sgml/runtime.sgml 20 Nov 2008 11:48:26 -0000 1.422
--- doc/src/sgml/runtime.sgml 15 Dec 2008 23:22:24 -0000
***************
*** 1087,1093 ****
<thead>
<row>
<entry>Name</>
! <entry>Approximate multiplier (bytes per increment) as of 8.3</>
</row>
</thead>
--- 1087,1093 ----
<thead>
<row>
<entry>Name</>
! <entry>Additional bytes per object, as of 8.3</>
</row>
</thead>
***************
*** 1119,1125 ****
<row>
<entry>Fixed space requirements</>
! <entry>770 kB</entry>
</row>
</tbody>
</tgroup>
--- 1119,1125 ----
<row>
<entry>Fixed space requirements</>
! <entry>770 k</entry>
</row>
</tbody>
</tgroup>
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-15 23:23 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
@ 2008-12-15 23:43 ` Alvaro Herrera <[email protected]>
2008-12-15 23:46 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
0 siblings, 1 reply; 28+ messages in thread
From: Alvaro Herrera @ 2008-12-15 23:43 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Tom Lane <[email protected]>; [email protected]; pgsql-docs; dx k9 <[email protected]>
Bruce Momjian wrote:
> Tom Lane wrote:
> > [ redirecting to pgsql-docs ]
> >
> > Valentin Bogdanov <[email protected]> writes:
> > >> From: dx k9 <[email protected]>
> > >> I'm trying to understand what the documentation means
> > >> by bytes per increment, what is the increment supposed to
> > >> be bytes, MB, or Kb.
> >
> > > shared_buffers is in disk block size, typically 8K, at least that's what it is on Linux platforms. shmmax is quite simply in bytes.
> >
> > The table the OP is looking at (table 17.2 in the 8.3 docs) predates
> > the ability to specify shared_buffers in KB or MB instead of
> > number-of-buffers. I agree it's not entirely obvious that what it
> > means is "multiply your setting in KB/MB by 8400/8192". Anybody have
> > an idea how to clarify things?
>
> I have updated the table title to be clearer.
I don't find it any clearer ... I think the missing clue is that if you
specify shared_buffers values in MB, you must divide the value by block
size.
> ***************
> *** 1119,1125 ****
>
> <row>
> <entry>Fixed space requirements</>
> ! <entry>770 kB</entry>
> </row>
> </tbody>
> </tgroup>
> --- 1119,1125 ----
>
> <row>
> <entry>Fixed space requirements</>
> ! <entry>770 k</entry>
> </row>
> </tbody>
> </tgroup>
This change is wrong, why did you do it?
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-15 23:23 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-15 23:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
@ 2008-12-15 23:46 ` Bruce Momjian <[email protected]>
2008-12-16 00:35 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
0 siblings, 1 reply; 28+ messages in thread
From: Bruce Momjian @ 2008-12-15 23:46 UTC (permalink / raw)
To: Alvaro Herrera <[email protected]>; +Cc: Tom Lane <[email protected]>; [email protected]; pgsql-docs; dx k9 <[email protected]>
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > [ redirecting to pgsql-docs ]
> > >
> > > Valentin Bogdanov <[email protected]> writes:
> > > >> From: dx k9 <[email protected]>
> > > >> I'm trying to understand what the documentation means
> > > >> by bytes per increment, what is the increment supposed to
> > > >> be bytes, MB, or Kb.
> > >
> > > > shared_buffers is in disk block size, typically 8K, at least that's what it is on Linux platforms. shmmax is quite simply in bytes.
> > >
> > > The table the OP is looking at (table 17.2 in the 8.3 docs) predates
> > > the ability to specify shared_buffers in KB or MB instead of
> > > number-of-buffers. I agree it's not entirely obvious that what it
> > > means is "multiply your setting in KB/MB by 8400/8192". Anybody have
> > > an idea how to clarify things?
> >
> > I have updated the table title to be clearer.
>
> I don't find it any clearer ... I think the missing clue is that if you
> specify shared_buffers values in MB, you must divide the value by block
> size.
Well, the heading says "object" now so I thought it would suggest we are
talking about objects and not bytes.
> > ***************
> > *** 1119,1125 ****
> >
> > <row>
> > <entry>Fixed space requirements</>
> > ! <entry>770 kB</entry>
> > </row>
> > </tbody>
> > </tgroup>
> > --- 1119,1125 ----
> >
> > <row>
> > <entry>Fixed space requirements</>
> > ! <entry>770 k</entry>
> > </row>
> > </tbody>
> > </tgroup>
>
> This change is wrong, why did you do it?
The heading says "bytes" so having the "B" was unnecessary and possibly
confusing.
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-15 23:23 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-15 23:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-15 23:46 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
@ 2008-12-16 00:35 ` Tom Lane <[email protected]>
2008-12-16 03:13 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
0 siblings, 1 reply; 28+ messages in thread
From: Tom Lane @ 2008-12-16 00:35 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; [email protected]; pgsql-docs; dx k9 <[email protected]>
Bruce Momjian <[email protected]> writes:
> Alvaro Herrera wrote:
>> I don't find it any clearer ... I think the missing clue is that if you
>> specify shared_buffers values in MB, you must divide the value by block
>> size.
> Well, the heading says "object" now so I thought it would suggest we are
> talking about objects and not bytes.
I'm with Alvaro: neither of those changes were improvements.
regards, tom lane
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-15 23:23 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-15 23:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-15 23:46 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 00:35 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
@ 2008-12-16 03:13 ` Bruce Momjian <[email protected]>
2008-12-16 14:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
0 siblings, 1 reply; 28+ messages in thread
From: Bruce Momjian @ 2008-12-16 03:13 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; [email protected]; pgsql-docs; dx k9 <[email protected]>
Tom Lane wrote:
> Bruce Momjian <[email protected]> writes:
> > Alvaro Herrera wrote:
> >> I don't find it any clearer ... I think the missing clue is that if you
> >> specify shared_buffers values in MB, you must divide the value by block
> >> size.
>
> > Well, the heading says "object" now so I thought it would suggest we are
> > talking about objects and not bytes.
>
> I'm with Alvaro: neither of those changes were improvements.
OK, I never got the change applied because of Alvaro's objection so
there is nothing to revert. Alvaro said he has an idea for improved
wording; I do not.
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-15 23:23 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-15 23:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-15 23:46 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 00:35 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-16 03:13 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
@ 2008-12-16 14:43 ` Alvaro Herrera <[email protected]>
2008-12-16 19:33 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
0 siblings, 1 reply; 28+ messages in thread
From: Alvaro Herrera @ 2008-12-16 14:43 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Tom Lane <[email protected]>; [email protected]; pgsql-docs; dx k9 <[email protected]>
Bruce Momjian wrote:
> OK, I never got the change applied because of Alvaro's objection so
> there is nothing to revert. Alvaro said he has an idea for improved
> wording; I do not.
I think we should add a more explicit note, like in the attached patch.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Attachments:
[text/x-diff] note-buffersize.patch (846B, 2-note-buffersize.patch)
download | inline diff:
Index: runtime.sgml
===================================================================
RCS file: /home/alvherre/Code/cvs/pgsql/doc/src/sgml/runtime.sgml,v
retrieving revision 1.422
diff -c -p -r1.422 runtime.sgml
*** runtime.sgml 20 Nov 2008 11:48:26 -0000 1.422
--- runtime.sgml 16 Dec 2008 14:40:42 -0000
*************** set semsys:seminfo_semmsl=32
*** 1124,1129 ****
--- 1124,1139 ----
</tbody>
</tgroup>
</table>
+
+ <note>
+ <para>
+ The multipliers for <varname>shared_buffers</> and
+ <varname>wal_buffers</> should be the number of buffers, not the
+ amount in bytes. To find out the number of shared or wal buffers, divide
+ the amount in bytes by <xref linkend="guc-block-size"> and
+ <xref linkend="guc-wal-block-size">, respectively.
+ </para>
+ </note>
</sect2>
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-15 23:23 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-15 23:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-15 23:46 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 00:35 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-16 03:13 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 14:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
@ 2008-12-16 19:33 ` Alvaro Herrera <[email protected]>
2008-12-16 22:06 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
0 siblings, 1 reply; 28+ messages in thread
From: Alvaro Herrera @ 2008-12-16 19:33 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Tom Lane <[email protected]>; [email protected]; pgsql-docs; dx k9 <[email protected]>
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > OK, I never got the change applied because of Alvaro's objection so
> > there is nothing to revert. Alvaro said he has an idea for improved
> > wording; I do not.
>
> I think we should add a more explicit note, like in the attached patch.
Committed. Bruce told me on IM he still wants to do more changes.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-15 23:23 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-15 23:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-15 23:46 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 00:35 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-16 03:13 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 14:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-16 19:33 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
@ 2008-12-16 22:06 ` Bruce Momjian <[email protected]>
2008-12-16 23:38 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
0 siblings, 1 reply; 28+ messages in thread
From: Bruce Momjian @ 2008-12-16 22:06 UTC (permalink / raw)
To: Alvaro Herrera <[email protected]>; +Cc: Tom Lane <[email protected]>; [email protected]; pgsql-docs; dx k9 <[email protected]>
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> > > OK, I never got the change applied because of Alvaro's objection so
> > > there is nothing to revert. Alvaro said he has an idea for improved
> > > wording; I do not.
> >
> > I think we should add a more explicit note, like in the attached patch.
>
> Committed. Bruce told me on IM he still wants to do more changes.
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
OK, updated patch. I added item descriptions and removed Alvaro's
paragraph; I worked with Alvaro on this patch.
You can see the output in table 17-2:
http://momjian.us/tmp/pgsql/kernel-resources.html
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Attachments:
[text/x-diff] /pgpatches/shared_mem_table (3.4K, 2-%2Fpgpatches%2Fshared_mem_table)
download | inline diff:
Index: doc/src/sgml/runtime.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v
retrieving revision 1.423
diff -c -c -r1.423 runtime.sgml
*** doc/src/sgml/runtime.sgml 16 Dec 2008 19:30:43 -0000 1.423
--- doc/src/sgml/runtime.sgml 16 Dec 2008 22:01:14 -0000
***************
*** 1087,1141 ****
<thead>
<row>
<entry>Name</>
! <entry>Approximate multiplier (bytes per increment) as of 8.3</>
</row>
</thead>
<tbody>
<row>
<entry><xref linkend="guc-max-connections"></>
! <entry>1800 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>
</row>
<row>
<entry><xref linkend="guc-autovacuum-max-workers"></>
! <entry>1800 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>
</row>
<row>
<entry><xref linkend="guc-max-prepared-transactions"></>
! <entry>770 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>
</row>
<row>
<entry><xref linkend="guc-shared-buffers"></>
! <entry>8400 (assuming 8 kB <symbol>BLCKSZ</>)</entry>
</row>
<row>
<entry><xref linkend="guc-wal-buffers"></>
! <entry>8200 (assuming 8 kB <symbol>XLOG_BLCKSZ</>)</entry>
</row>
<row>
<entry>Fixed space requirements</>
! <entry>770 kB</entry>
</row>
</tbody>
</tgroup>
</table>
! <note>
! <para>
! The multipliers for <varname>shared_buffers</> and
! <varname>wal_buffers</> should be the number of buffers, not the
! amount in bytes. To find out the number of shared or wal buffers, divide
! the amount in bytes by <xref linkend="guc-block-size"> and
! <xref linkend="guc-wal-block-size">, respectively.
! </para>
! </note>
! </sect2>
!
<sect2>
<title>Resource Limits</title>
--- 1087,1137 ----
<thead>
<row>
<entry>Name</>
! <entry>Shared memory requirements, as of 8.3</>
</row>
</thead>
<tbody>
<row>
<entry><xref linkend="guc-max-connections"></>
! <entry>1800 + 270 * <xref
! linkend="guc-max-locks-per-transaction"> bytes per connection</entry>
</row>
<row>
<entry><xref linkend="guc-autovacuum-max-workers"></>
! <entry>1800 + 270 * <xref
! linkend="guc-max-locks-per-transaction"> bytes per worker</entry>
</row>
<row>
<entry><xref linkend="guc-max-prepared-transactions"></>
! <entry>770 + 270 * <xref
! linkend="guc-max-locks-per-transaction"> bytes per prepared transaction</entry>
</row>
<row>
<entry><xref linkend="guc-shared-buffers"></>
! <entry><xref linkend="guc-block-size"> + 208 bytes per shared buffer</entry>
</row>
<row>
<entry><xref linkend="guc-wal-buffers"></>
! <entry><xref linkend="guc-wal-block-size"> + 8 bytes per WAL buffer</entry>
</row>
<row>
<entry>Fixed space requirements</>
! <entry>770k bytes</entry>
</row>
</tbody>
</tgroup>
</table>
! <para>
! These shared memory allocations are reserved at database server
! start and remain static.
! </para>
<sect2>
<title>Resource Limits</title>
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-15 23:23 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-15 23:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-15 23:46 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 00:35 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-16 03:13 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 14:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-16 19:33 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-16 22:06 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
@ 2008-12-16 23:38 ` Tom Lane <[email protected]>
2008-12-17 01:33 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
0 siblings, 1 reply; 28+ messages in thread
From: Tom Lane @ 2008-12-16 23:38 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; [email protected]; pgsql-docs; dx k9 <[email protected]>
Bruce Momjian <[email protected]> writes:
> OK, updated patch. I added item descriptions and removed Alvaro's
> paragraph; I worked with Alvaro on this patch.
This still seems pretty misleading, as for example
> <tbody>
> <row>
> <entry><xref linkend="guc-max-connections"></>
> ! <entry>1800 + 270 * <xref
> ! linkend="guc-max-locks-per-transaction"> bytes per connection</entry>
> </row>
sounds like it might mean bytes per *active* connection, when of course
the correct way to figure it is by multiplying by max_connections.
If you're going to give a formula, why not just give a formula, eg
(1800 + 270 * max_locks_per_transaction) * (max_connections + autovacuum_max_workers)
regards, tom lane
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-15 23:23 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-15 23:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-15 23:46 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 00:35 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-16 03:13 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 14:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-16 19:33 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-16 22:06 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 23:38 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
@ 2008-12-17 01:33 ` Bruce Momjian <[email protected]>
2008-12-17 03:31 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
0 siblings, 1 reply; 28+ messages in thread
From: Bruce Momjian @ 2008-12-17 01:33 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; [email protected]; pgsql-docs; dx k9 <[email protected]>
Tom Lane wrote:
> Bruce Momjian <[email protected]> writes:
> > OK, updated patch. I added item descriptions and removed Alvaro's
> > paragraph; I worked with Alvaro on this patch.
>
> This still seems pretty misleading, as for example
>
> > <tbody>
> > <row>
> > <entry><xref linkend="guc-max-connections"></>
> > ! <entry>1800 + 270 * <xref
> > ! linkend="guc-max-locks-per-transaction"> bytes per connection</entry>
> > </row>
>
> sounds like it might mean bytes per *active* connection, when of course
> the correct way to figure it is by multiplying by max_connections.
> If you're going to give a formula, why not just give a formula, eg
>
> (1800 + 270 * max_locks_per_transaction) * (max_connections + autovacuum_max_workers)
>
> regards, tom lane
You mean like this:
http://momjian.us/tmp/pgsql/kernel-resources.html
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/runtime.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v
retrieving revision 1.423
diff -c -c -r1.423 runtime.sgml
*** doc/src/sgml/runtime.sgml 16 Dec 2008 19:30:43 -0000 1.423
--- doc/src/sgml/runtime.sgml 17 Dec 2008 01:30:21 -0000
***************
*** 1087,1141 ****
<thead>
<row>
<entry>Name</>
! <entry>Approximate multiplier (bytes per increment) as of 8.3</>
</row>
</thead>
<tbody>
<row>
! <entry><xref linkend="guc-max-connections"></>
! <entry>1800 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>
! </row>
!
! <row>
! <entry><xref linkend="guc-autovacuum-max-workers"></>
! <entry>1800 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>
</row>
<row>
<entry><xref linkend="guc-max-prepared-transactions"></>
! <entry>770 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>
</row>
<row>
<entry><xref linkend="guc-shared-buffers"></>
! <entry>8400 (assuming 8 kB <symbol>BLCKSZ</>)</entry>
</row>
<row>
<entry><xref linkend="guc-wal-buffers"></>
! <entry>8200 (assuming 8 kB <symbol>XLOG_BLCKSZ</>)</entry>
</row>
<row>
<entry>Fixed space requirements</>
! <entry>770 kB</entry>
</row>
</tbody>
</tgroup>
</table>
! <note>
! <para>
! The multipliers for <varname>shared_buffers</> and
! <varname>wal_buffers</> should be the number of buffers, not the
! amount in bytes. To find out the number of shared or wal buffers, divide
! the amount in bytes by <xref linkend="guc-block-size"> and
! <xref linkend="guc-wal-block-size">, respectively.
! </para>
! </note>
! </sect2>
!
<sect2>
<title>Resource Limits</title>
--- 1087,1132 ----
<thead>
<row>
<entry>Name</>
! <entry>Shared memory bytes required, as of 8.3</>
</row>
</thead>
<tbody>
<row>
! <entry><xref linkend="guc-max-connections">, <xref linkend="guc-autovacuum-max-workers"></>
! <entry>(1800 + 270 * <xref
! linkend="guc-max-locks-per-transaction">) * (<xref
! linkend="guc-max-connections"> + <xref linkend="guc-autovacuum-max-workers">)</entry>
</row>
<row>
<entry><xref linkend="guc-max-prepared-transactions"></>
! <entry>(770 + 270 * <xref
! linkend="guc-max-locks-per-transaction">) * <xref linkend="guc-max-prepared-transactions"></entry>
</row>
<row>
<entry><xref linkend="guc-shared-buffers"></>
! <entry>(<xref linkend="guc-block-size"> + 208) * <xref linkend="guc-shared-buffers"></entry>
</row>
<row>
<entry><xref linkend="guc-wal-buffers"></>
! <entry>(<xref linkend="guc-wal-block-size"> + 8) * <xref linkend="guc-wal-buffers"></entry>
</row>
<row>
<entry>Fixed space requirements</>
! <entry>770k bytes</entry>
</row>
</tbody>
</tgroup>
</table>
! <para>
! These shared memory allocations are reserved at database server
! start and remain static.
! </para>
<sect2>
<title>Resource Limits</title>
Attachments:
[text/plain] /pgpatches/shared_mem_table (3.4K, 2-%2Fpgpatches%2Fshared_mem_table)
download | inline:
Index: doc/src/sgml/runtime.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v
retrieving revision 1.423
diff -c -c -r1.423 runtime.sgml
*** doc/src/sgml/runtime.sgml 16 Dec 2008 19:30:43 -0000 1.423
--- doc/src/sgml/runtime.sgml 17 Dec 2008 01:30:21 -0000
***************
*** 1087,1141 ****
<thead>
<row>
<entry>Name</>
! <entry>Approximate multiplier (bytes per increment) as of 8.3</>
</row>
</thead>
<tbody>
<row>
! <entry><xref linkend="guc-max-connections"></>
! <entry>1800 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>
! </row>
!
! <row>
! <entry><xref linkend="guc-autovacuum-max-workers"></>
! <entry>1800 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>
</row>
<row>
<entry><xref linkend="guc-max-prepared-transactions"></>
! <entry>770 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>
</row>
<row>
<entry><xref linkend="guc-shared-buffers"></>
! <entry>8400 (assuming 8 kB <symbol>BLCKSZ</>)</entry>
</row>
<row>
<entry><xref linkend="guc-wal-buffers"></>
! <entry>8200 (assuming 8 kB <symbol>XLOG_BLCKSZ</>)</entry>
</row>
<row>
<entry>Fixed space requirements</>
! <entry>770 kB</entry>
</row>
</tbody>
</tgroup>
</table>
! <note>
! <para>
! The multipliers for <varname>shared_buffers</> and
! <varname>wal_buffers</> should be the number of buffers, not the
! amount in bytes. To find out the number of shared or wal buffers, divide
! the amount in bytes by <xref linkend="guc-block-size"> and
! <xref linkend="guc-wal-block-size">, respectively.
! </para>
! </note>
! </sect2>
!
<sect2>
<title>Resource Limits</title>
--- 1087,1132 ----
<thead>
<row>
<entry>Name</>
! <entry>Shared memory bytes required, as of 8.3</>
</row>
</thead>
<tbody>
<row>
! <entry><xref linkend="guc-max-connections">, <xref linkend="guc-autovacuum-max-workers"></>
! <entry>(1800 + 270 * <xref
! linkend="guc-max-locks-per-transaction">) * (<xref
! linkend="guc-max-connections"> + <xref linkend="guc-autovacuum-max-workers">)</entry>
</row>
<row>
<entry><xref linkend="guc-max-prepared-transactions"></>
! <entry>(770 + 270 * <xref
! linkend="guc-max-locks-per-transaction">) * <xref linkend="guc-max-prepared-transactions"></entry>
</row>
<row>
<entry><xref linkend="guc-shared-buffers"></>
! <entry>(<xref linkend="guc-block-size"> + 208) * <xref linkend="guc-shared-buffers"></entry>
</row>
<row>
<entry><xref linkend="guc-wal-buffers"></>
! <entry>(<xref linkend="guc-wal-block-size"> + 8) * <xref linkend="guc-wal-buffers"></entry>
</row>
<row>
<entry>Fixed space requirements</>
! <entry>770k bytes</entry>
</row>
</tbody>
</tgroup>
</table>
! <para>
! These shared memory allocations are reserved at database server
! start and remain static.
! </para>
<sect2>
<title>Resource Limits</title>
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-15 23:23 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-15 23:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-15 23:46 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 00:35 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-16 03:13 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 14:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-16 19:33 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-16 22:06 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 23:38 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-17 01:33 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
@ 2008-12-17 03:31 ` Tom Lane <[email protected]>
2008-12-17 13:41 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
0 siblings, 1 reply; 28+ messages in thread
From: Tom Lane @ 2008-12-17 03:31 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; [email protected]; pgsql-docs; dx k9 <[email protected]>
Bruce Momjian <[email protected]> writes:
> Tom Lane wrote:
>> If you're going to give a formula, why not just give a formula, eg
> You mean like this:
> http://momjian.us/tmp/pgsql/kernel-resources.html
Yeah, more or less. A couple thoughts now that I see it worked out:
* Combining the entries for max_connections and autovacuum_max_workers
is probably just making it look more complicated than it needs to.
How about two rows that just happen to have similar formulas, viz
max_connections (1800 + 270 * max_locks_per_transaction) * max_connections
autovacuum_max_workers (1800 + 270 * max_locks_per_transaction) * autovacuum_max_workers
* The right-hand column header should be something like "Approximate
shared memory bytes..." to avoid the impression that these formulas
are meant to be exact.
* If we do it like this then the left-hand column is really redundant,
not to say wrong because the right-hand formulas depend on more than
the single variable mentioned. How about something like
Table 17-2 PostgreSQL shared memory usage
Purpose Approximate number of bytes required (as of 8.3)
Per-connection state (1800 + 270 * max_locks_per_transaction) * max_connections
Autovacuum worker state (1800 + 270 * max_locks_per_transaction) * autovacuum_max_workers
Prepared transaction state ...
Shared disk buffers ...
WAL buffers ...
Fixed space requirements 770kB
regards, tom lane
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-15 23:23 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-15 23:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-15 23:46 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 00:35 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-16 03:13 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 14:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-16 19:33 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-16 22:06 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 23:38 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-17 01:33 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-17 03:31 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
@ 2008-12-17 13:41 ` Bruce Momjian <[email protected]>
2008-12-17 13:53 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
0 siblings, 1 reply; 28+ messages in thread
From: Bruce Momjian @ 2008-12-17 13:41 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; [email protected]; pgsql-docs; dx k9 <[email protected]>
Tom Lane wrote:
> Bruce Momjian <[email protected]> writes:
> > Tom Lane wrote:
> >> If you're going to give a formula, why not just give a formula, eg
>
> > You mean like this:
> > http://momjian.us/tmp/pgsql/kernel-resources.html
>
> Yeah, more or less. A couple thoughts now that I see it worked out:
>
> * Combining the entries for max_connections and autovacuum_max_workers
> is probably just making it look more complicated than it needs to.
> How about two rows that just happen to have similar formulas, viz
>
> max_connections (1800 + 270 * max_locks_per_transaction) * max_connections
> autovacuum_max_workers (1800 + 270 * max_locks_per_transaction) * autovacuum_max_workers
>
> * The right-hand column header should be something like "Approximate
> shared memory bytes..." to avoid the impression that these formulas
> are meant to be exact.
>
> * If we do it like this then the left-hand column is really redundant,
> not to say wrong because the right-hand formulas depend on more than
> the single variable mentioned. How about something like
>
> Table 17-2 PostgreSQL shared memory usage
>
> Purpose Approximate number of bytes required (as of 8.3)
>
> Per-connection state (1800 + 270 * max_locks_per_transaction) * max_connections
> Autovacuum worker state (1800 + 270 * max_locks_per_transaction) * autovacuum_max_workers
> Prepared transaction state ...
> Shared disk buffers ...
> WAL buffers ...
> Fixed space requirements 770kB
OK, I updated it again:
http://momjian.us/tmp/pgsql/kernel-resources.html
I did change your left column wording because it could be interpreted as
something that changes during server execution, e.g. connections.
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-15 23:23 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-15 23:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-15 23:46 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 00:35 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-16 03:13 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 14:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-16 19:33 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-16 22:06 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 23:38 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-17 01:33 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-17 03:31 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-17 13:41 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
@ 2008-12-17 13:53 ` Tom Lane <[email protected]>
2008-12-17 14:11 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
0 siblings, 1 reply; 28+ messages in thread
From: Tom Lane @ 2008-12-17 13:53 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; [email protected]; pgsql-docs; dx k9 <[email protected]>
Bruce Momjian <[email protected]> writes:
> Tom Lane wrote:
>> * If we do it like this then the left-hand column is really redundant,
>> not to say wrong because the right-hand formulas depend on more than
>> the single variable mentioned. How about something like
>>
>> Table 17-2 PostgreSQL shared memory usage
>>
>> Purpose Approximate number of bytes required (as of 8.3)
>>
>> Per-connection state (1800 + 270 * max_locks_per_transaction) * max_connections
>> Autovacuum worker state (1800 + 270 * max_locks_per_transaction) * autovacuum_max_workers
>> Prepared transaction state ...
>> Shared disk buffers ...
>> WAL buffers ...
>> Fixed space requirements 770kB
> OK, I updated it again:
> http://momjian.us/tmp/pgsql/kernel-resources.html
> I did change your left column wording because it could be interpreted as
> something that changes during server execution, e.g. connections.
[ shrug... ] I don't find what you did to be an improvement over what
I suggested, but I don't have time to argue about it.
regards, tom lane
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-15 23:23 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-15 23:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-15 23:46 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 00:35 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-16 03:13 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 14:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-16 19:33 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-16 22:06 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 23:38 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-17 01:33 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-17 03:31 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-17 13:41 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-17 13:53 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
@ 2008-12-17 14:11 ` Bruce Momjian <[email protected]>
2008-12-17 15:20 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
0 siblings, 1 reply; 28+ messages in thread
From: Bruce Momjian @ 2008-12-17 14:11 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; [email protected]; pgsql-docs; dx k9 <[email protected]>
Tom Lane wrote:
> Bruce Momjian <[email protected]> writes:
> > Tom Lane wrote:
> >> * If we do it like this then the left-hand column is really redundant,
> >> not to say wrong because the right-hand formulas depend on more than
> >> the single variable mentioned. How about something like
> >>
> >> Table 17-2 PostgreSQL shared memory usage
> >>
> >> Purpose Approximate number of bytes required (as of 8.3)
> >>
> >> Per-connection state (1800 + 270 * max_locks_per_transaction) * max_connections
> >> Autovacuum worker state (1800 + 270 * max_locks_per_transaction) * autovacuum_max_workers
> >> Prepared transaction state ...
> >> Shared disk buffers ...
> >> WAL buffers ...
> >> Fixed space requirements 770kB
>
> > OK, I updated it again:
>
> > http://momjian.us/tmp/pgsql/kernel-resources.html
>
> > I did change your left column wording because it could be interpreted as
> > something that changes during server execution, e.g. connections.
>
> [ shrug... ] I don't find what you did to be an improvement over what
> I suggested, but I don't have time to argue about it.
I decided I didn't like what I did either; updated version with new
headings and shorter descriptions:
http://momjian.us/tmp/pgsql/kernel-resources.html
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-15 23:23 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-15 23:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-15 23:46 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 00:35 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-16 03:13 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 14:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-16 19:33 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-16 22:06 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 23:38 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-17 01:33 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-17 03:31 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-17 13:41 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-17 13:53 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-17 14:11 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
@ 2008-12-17 15:20 ` Alvaro Herrera <[email protected]>
2008-12-18 17:07 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
0 siblings, 1 reply; 28+ messages in thread
From: Alvaro Herrera @ 2008-12-17 15:20 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Tom Lane <[email protected]>; [email protected]; pgsql-docs; dx k9 <[email protected]>
Bruce Momjian wrote:
> I decided I didn't like what I did either; updated version with new
> headings and shorter descriptions:
>
> http://momjian.us/tmp/pgsql/kernel-resources.html
This version seems good to me, except please put back the B to the end
of "770 k".
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-15 23:23 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-15 23:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-15 23:46 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 00:35 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-16 03:13 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 14:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-16 19:33 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-16 22:06 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 23:38 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-17 01:33 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-17 03:31 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-17 13:41 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-17 13:53 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-17 14:11 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-17 15:20 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
@ 2008-12-18 17:07 ` Bruce Momjian <[email protected]>
2008-12-18 17:10 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
0 siblings, 1 reply; 28+ messages in thread
From: Bruce Momjian @ 2008-12-18 17:07 UTC (permalink / raw)
To: Alvaro Herrera <[email protected]>; +Cc: Tom Lane <[email protected]>; [email protected]; pgsql-docs; dx k9 <[email protected]>
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > I decided I didn't like what I did either; updated version with new
> > headings and shorter descriptions:
> >
> > http://momjian.us/tmp/pgsql/kernel-resources.html
>
> This version seems good to me, except please put back the B to the end
> of "770 k".
Patch applied with "B" re-added, though I would like to mention again
that it is inconsistent because we don't mention bytes in any other row
in that column.
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Attachments:
[text/x-diff] /rtmp/diff (3.8K, 2-%2Frtmp%2Fdiff)
download | inline diff:
Index: runtime.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v
retrieving revision 1.423
retrieving revision 1.424
diff -c -c -r1.423 -r1.424
*** runtime.sgml 16 Dec 2008 19:30:43 -0000 1.423
--- runtime.sgml 18 Dec 2008 17:03:09 -0000 1.424
***************
*** 1,4 ****
! <!-- $PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.423 2008/12/16 19:30:43 alvherre Exp $ -->
<chapter Id="runtime">
<title>Operating System Environment</title>
--- 1,4 ----
! <!-- $PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.424 2008/12/18 17:03:09 momjian Exp $ -->
<chapter Id="runtime">
<title>Operating System Environment</title>
***************
*** 1080,1120 ****
<table id="shared-memory-parameters">
! <title>Configuration parameters affecting
! <productname>PostgreSQL</productname>'s shared memory usage</>
<tgroup cols="2">
<thead>
<row>
! <entry>Name</>
! <entry>Approximate multiplier (bytes per increment) as of 8.3</>
</row>
</thead>
<tbody>
<row>
! <entry><xref linkend="guc-max-connections"></>
! <entry>1800 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>
</row>
<row>
! <entry><xref linkend="guc-autovacuum-max-workers"></>
! <entry>1800 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>
</row>
<row>
! <entry><xref linkend="guc-max-prepared-transactions"></>
! <entry>770 + 270 * <xref linkend="guc-max-locks-per-transaction"></entry>
</row>
<row>
! <entry><xref linkend="guc-shared-buffers"></>
! <entry>8400 (assuming 8 kB <symbol>BLCKSZ</>)</entry>
</row>
<row>
! <entry><xref linkend="guc-wal-buffers"></>
! <entry>8200 (assuming 8 kB <symbol>XLOG_BLCKSZ</>)</entry>
</row>
<row>
--- 1080,1124 ----
<table id="shared-memory-parameters">
! <title><productname>PostgreSQL</productname> shared memory usage</>
<tgroup cols="2">
<thead>
<row>
! <entry>Usage</>
! <entry>Approximate shared memory bytes required (as of 8.3)</>
</row>
</thead>
<tbody>
<row>
! <entry>Connections</>
! <entry>(1800 + 270 * <xref
! linkend="guc-max-locks-per-transaction">) * <xref
! linkend="guc-max-connections"></entry>
</row>
<row>
! <entry>Autovacuum workers</>
! <entry>(1800 + 270 * <xref
! linkend="guc-max-locks-per-transaction">) * <xref
! linkend="guc-autovacuum-max-workers"></entry>
</row>
<row>
! <entry>Prepared transactions</>
! <entry>(770 + 270 * <xref
! linkend="guc-max-locks-per-transaction">) * <xref linkend="guc-max-prepared-transactions"></entry>
</row>
<row>
! <entry>Shared disk buffers</>
! <entry>(<xref linkend="guc-block-size"> + 208) * <xref linkend="guc-shared-buffers"></entry>
</row>
<row>
! <entry>WAL buffers</>
! <entry>(<xref linkend="guc-wal-block-size"> + 8) * <xref linkend="guc-wal-buffers"></entry>
</row>
<row>
***************
*** 1125,1142 ****
</tgroup>
</table>
- <note>
- <para>
- The multipliers for <varname>shared_buffers</> and
- <varname>wal_buffers</> should be the number of buffers, not the
- amount in bytes. To find out the number of shared or wal buffers, divide
- the amount in bytes by <xref linkend="guc-block-size"> and
- <xref linkend="guc-wal-block-size">, respectively.
- </para>
- </note>
</sect2>
-
<sect2>
<title>Resource Limits</title>
--- 1129,1136 ----
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: [ADMIN] shared_buffers and shmmax
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Re: shared_buffers and shmmax Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-15 23:23 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-15 23:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-15 23:46 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 00:35 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-16 03:13 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 14:43 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-16 19:33 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-16 22:06 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-16 23:38 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-17 01:33 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-17 03:31 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-17 13:41 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-17 13:53 ` Re: [ADMIN] shared_buffers and shmmax Tom Lane <[email protected]>
2008-12-17 14:11 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
2008-12-17 15:20 ` Re: [ADMIN] shared_buffers and shmmax Alvaro Herrera <[email protected]>
2008-12-18 17:07 ` Re: [ADMIN] shared_buffers and shmmax Bruce Momjian <[email protected]>
@ 2008-12-18 17:10 ` Alvaro Herrera <[email protected]>
0 siblings, 0 replies; 28+ messages in thread
From: Alvaro Herrera @ 2008-12-18 17:10 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Tom Lane <[email protected]>; [email protected]; pgsql-docs; dx k9 <[email protected]>
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > This version seems good to me, except please put back the B to the end
> > of "770 k".
>
> Patch applied with "B" re-added, though I would like to mention again
> that it is inconsistent because we don't mention bytes in any other row
> in that column.
The heading already says "bytes".
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
^ permalink raw reply [nested|flat] 28+ messages in thread
end of thread, other threads:[~2008-12-18 17:10 UTC | newest]
Thread overview: 28+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2008-07-22 13:39 shared_buffers and shmmax dx k9 <[email protected]>
2008-07-22 14:08 ` Valentin Bogdanov <[email protected]>
2008-07-22 14:45 ` Tom Lane <[email protected]>
2008-07-22 19:30 ` Francisco Reyes <[email protected]>
2008-07-24 17:54 ` Greg Sabino Mullane <[email protected]>
2008-07-24 18:02 ` Joshua D. Drake <[email protected]>
2008-07-26 21:47 ` Greg Smith <[email protected]>
2008-08-12 17:48 ` Bruce Momjian <[email protected]>
2008-08-12 19:43 ` Greg Smith <[email protected]>
2008-08-22 05:49 ` Decibel! <[email protected]>
2008-12-15 23:32 ` Bruce Momjian <[email protected]>
2008-12-15 23:23 ` Bruce Momjian <[email protected]>
2008-12-15 23:43 ` Alvaro Herrera <[email protected]>
2008-12-15 23:46 ` Bruce Momjian <[email protected]>
2008-12-16 00:35 ` Tom Lane <[email protected]>
2008-12-16 03:13 ` Bruce Momjian <[email protected]>
2008-12-16 14:43 ` Alvaro Herrera <[email protected]>
2008-12-16 19:33 ` Alvaro Herrera <[email protected]>
2008-12-16 22:06 ` Bruce Momjian <[email protected]>
2008-12-16 23:38 ` Tom Lane <[email protected]>
2008-12-17 01:33 ` Bruce Momjian <[email protected]>
2008-12-17 03:31 ` Tom Lane <[email protected]>
2008-12-17 13:41 ` Bruce Momjian <[email protected]>
2008-12-17 13:53 ` Tom Lane <[email protected]>
2008-12-17 14:11 ` Bruce Momjian <[email protected]>
2008-12-17 15:20 ` Alvaro Herrera <[email protected]>
2008-12-18 17:07 ` Bruce Momjian <[email protected]>
2008-12-18 17:10 ` Alvaro Herrera <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox