Thread: Re: [ADMIN] shared_buffers and shmmax
[ redirecting to pgsql-docs ]
Valentin Bogdanov <valiouk@yahoo.co.uk> writes:
>> From: dx k9 <bitsandbytes88@hotmail.com>
>> 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
simplyin 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
On 10:45 am 07/22/08 Tom Lane <tgl@sss.pgh.pa.us> 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.
-----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 greg@turnstep.com
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-----
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 gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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 gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
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 decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828
Attachment
Tom Lane wrote: > [ redirecting to pgsql-docs ] > > Valentin Bogdanov <valiouk@yahoo.co.uk> writes: > >> From: dx k9 <bitsandbytes88@hotmail.com> > >> 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 simplyin 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 <bruce@momjian.us> 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.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>
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 greg@turnstep.com
> 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 (pgsql-docs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-docs
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Tom Lane wrote: > > [ redirecting to pgsql-docs ] > > > > Valentin Bogdanov <valiouk@yahoo.co.uk> writes: > > >> From: dx k9 <bitsandbytes88@hotmail.com> > > >> 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 quitesimply 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
Alvaro Herrera wrote: > Bruce Momjian wrote: > > Tom Lane wrote: > > > [ redirecting to pgsql-docs ] > > > > > > Valentin Bogdanov <valiouk@yahoo.co.uk> writes: > > > >> From: dx k9 <bitsandbytes88@hotmail.com> > > > >> 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 quitesimply 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> 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
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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.
Attachment
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.
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 <bruce@momjian.us> 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 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>
Bruce Momjian <bruce@momjian.us> 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
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> 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 <bruce@momjian.us> 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>
Bruce Momjian <bruce@momjian.us> 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
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> 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
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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
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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + 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 ----
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.