public inbox for [email protected]help / color / mirror / Atom feed
shared_buffers and shmmax 28+ messages / 10 participants [nested] [flat]
* shared_buffers and shmmax @ 2008-07-22 13:39 dx k9 <[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 14:08 Valentin Bogdanov <[email protected]> parent: dx k9 <[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 14:45 Tom Lane <[email protected]> parent: Valentin Bogdanov <[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 19:30 Francisco Reyes <[email protected]> parent: Tom Lane <[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-24 17:54 Greg Sabino Mullane <[email protected]> parent: Tom Lane <[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-24 18:02 Joshua D. Drake <[email protected]> parent: Greg Sabino Mullane <[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-26 21:47 Greg Smith <[email protected]> parent: Greg Sabino Mullane <[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-08-12 17:48 Bruce Momjian <[email protected]> parent: 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-08-12 19:43 Greg Smith <[email protected]> parent: Bruce Momjian <[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-08-22 05:49 Decibel! <[email protected]> parent: Greg Smith <[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-12-15 23:23 Bruce Momjian <[email protected]> parent: Tom Lane <[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-12-15 23:32 Bruce Momjian <[email protected]> parent: Greg Sabino Mullane <[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-12-15 23:43 Alvaro Herrera <[email protected]> parent: 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-12-15 23:46 Bruce Momjian <[email protected]> parent: Alvaro Herrera <[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-12-16 00:35 Tom Lane <[email protected]> parent: 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-12-16 03:13 Bruce Momjian <[email protected]> parent: Tom Lane <[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-12-16 14:43 Alvaro Herrera <[email protected]> parent: Bruce Momjian <[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-12-16 19:33 Alvaro Herrera <[email protected]> parent: Alvaro Herrera <[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-12-16 22:06 Bruce Momjian <[email protected]> parent: Alvaro Herrera <[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-12-16 23:38 Tom Lane <[email protected]> parent: 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-12-17 01:33 Bruce Momjian <[email protected]> parent: 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-12-17 03:31 Tom Lane <[email protected]> parent: 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-12-17 13:41 Bruce Momjian <[email protected]> parent: 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-12-17 13:53 Tom Lane <[email protected]> parent: 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-12-17 14:11 Bruce Momjian <[email protected]> parent: Tom Lane <[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-12-17 15:20 Alvaro Herrera <[email protected]> parent: 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-12-18 17:07 Bruce Momjian <[email protected]> parent: 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-12-18 17:10 Alvaro Herrera <[email protected]> parent: Bruce Momjian <[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